In theory you could make \UseExplPackage load the necessary machinery if not already done prior to processing it's arguments.
However, I'm not sure key val on the level of packages is really the way forward at least not in the way the2e mechanism operated. But to determine this the relationship to templates and to the LDB would need sorting out first and so I think adding a mechanism now that will need alterations or deprecation afterwards is premature at the moment.
... written on the iPad
Am 18.07.2013 um 10:02 schrieb Joseph Wright <[log in to unmask]>:
> On 17/07/2013 19:27, Joel C. Salomon wrote:
>> Joseph Wright <joseph.wright@...> writes:
>>> At present I'm waiting to see what people thing of the code-level stuff.
>>> At the same time, I'm not sure about making package option processing
>>> too complex. The lesson I've learned is that keyval in options is
>>> governed by the LaTeX2e kernel: options are expanded, and checking for
>>> clashes doesn't 'know' about keyval. Thus I tend to think load-time
>>> options should really be limited to things that need to happen there,
>>> with later \<thing>setup to cover more complex option sets.
>> Is the behavior of package & class options expected to be different
>> (specifically, keyval-aware) in a LaTeX3 kernel? If so, would it be
>> appropriate to define \UseExplPackage et al. so that the future behavior can
>> be experimented with?
> Not really worthwhile. The way that the LaTeX2e kernel does option
> processing means that expansion/space stripping happens 'early'. As
> such, you can't alter it in a way that is easy. Look at the option
> keyval-patching code in xkeyval and kvoptions to see this: you have to
> pre-load an additional package before the one where you want 'new'
> effects. Until we actually have the basics of a new format, this isn't
> going to help.
> Joseph Wright