Hello Ulrike,

>> I wonder if the pgfkeys idea of using one macro to create and set keys
>> is confusing. 

[snip]

>> do other people think that strict separation:

[snip]

>> is clearer?
> 
> Yes. 

Okay, that fits with what I've been thinking.  I'll look at this again
and implement what I've suggested in my mail.

>> The other question is how to make keys in this way. keys3 uses the idea
>> of properties:
>>
>>   key name/.property = value
>>
>> for example
>>
>>   \module\my~key/.tl_set:N  = \l_module_my_tl,
>>   \module\my~key/.default:n = {default}
>>
>> to create a key which will store its input in a tl. On the other hand,
>> template uses and "extended key-value" approach:
>>
>> key name =<type> [default] <function>
>>
>> for example:
>>
>>   my key =n [default] \l_module_my_tl

[snip]

> I would prefer the two step method -- because it probably means that
> you can change the default independently from the function. 

That again fits broadly with my thinking.

> (I haven't never really tried to use pgfkeys because the last time I
> looked at it it wasn't babel safe and all the spaces in the key
> names in the documentation make me nervous.) 

The babel problem remains with pgfkeys. Not a problem for LaTeX3 as
everything will be built on l3keyval, which is active-character safe (or
more accurately, has two routines, one of which is babel-safe and is
therefore for user input).  The spaces really should not be an issue: it
is all building things from csname. With LaTeX2e package options with
spaces *are* a problem, but that is not an issue for run-time keys and
should not be for LaTeX3 package options!
-- 
Joseph Wright