As I have (finally) some practical experience of using templates (kind of late, but the stuff I've been doing the last year haven't involved much design), I have encountered some general issues about templates that I think need some thought: 1. The order of parameter assignments. I haven't seen anything in the documentation about in which order the code for the various keys get executed, but in the implementation it looks as if they are executed in the order they are listed. It would be nice if this could be put in writing since you sometimes need one assignment to be carried out before another (my concrete example of this is that an instance key gets used in code for an `s' key). 2. The nature of the `n' key type Are `n' keys evaluated (expanded) at declaration-time or not? template.dtx is actually contradicting itself on this matter: in Section 1 it says `n' is the same thing as `f0', but in Subsection 3.1 there is an example using \DelayEvaluation in the default for a type `n' key to avoid declaration-time evaluation. As far as I can tell the implementation takes a third position as it parses a \MultiSelection but otherwise leaves the code unevaluated. My gut feeling is that the values for these keys should be evaluated at declaration, although so far I haven't been able to come up with any example where this is really needed. Anyway, if the declaration-time expansion is done as \edef\name@value{<default>} then a \DelayEvaluation can be defined through \def\DelayEvaluation#1{% \iffalse{\fi}% \toks@=\expandafter{\name@value #1}% \edef\name@value{\iffalse}\fi \the\toks@ } and \MultiSelection can be defined using a similar trick. Since names are things that are to end up between a \csname and the matching \endcsname it should be safe to use an unprotected \edef here. Of course there would have to be some formal specification of what you can put in an `n' type value in this case, but some discussions in the past (such as that about declaring an \"A instance for xinitials [1]) suggest to me that such a specification is needed for other reasons as well and has been for some time. A comparison with fontinst might also be useful here. Although I don't think it is spelt out like this anywhere, fontinst makes a distinction between string variables (the values of which are fully evaluated/expanded when they are assigned) and command variables (where no expansion takes place until they are used). Thus what I'm suggesting is that `n' type keys should work like string variables, whereas `f<n>' type keys should work like command variables. But I think that is all I've come up with, for the moment. Lars Hellström [1] About xinitials: The problem with that is of course not in the template, but in the document command which passes general text to an argument which expects a name value. The right thing to do would be to mangle the argument into a working name before trying to use it as an instance name. (A sketch for a mangling procedure would be the following: Require that the text to mangle is robust and doesn't contain any TeX primitives. Define representations for the text commands. Throw away all commands which aren't text commands---making \protect temporarily \@gobble should take care of that. Besides that something needs to be done about the \chardef tokens \% and \&; making them proper text commands is probably the way to go.)