On 18/09/2010 08:57, Frank Mittelbach wrote:
> Joseph Wright writes:
>   >  On 17/09/2010 20:36, Frank Mittelbach wrote:
>   >  >  since you already looked at the different implementations, any suggestion on
>   >  >  how to best improve the LaTeX2e behaviour?
>   >
>   >  I take it that this does possibly count as a bug then, rather than as a
>   >  'feature'?
>
> it doesn't count as a bug I would say, for the simple reason that per
> specification the optional argument of \usepackage doesn't support a key value
> list but just a list of option names (that themselves have no spaces)
> separated by comma. Only  later packages appeared that internally added
> something like keyval and manipulated the received option list from
> \usepackage as a key/val list, but that happens after \usepackage has already
> removed spaces and unfortunately in this case also the braces.
>
> pragmatic approach:
>
>   you state that one needs to say ={,}  to make things work as this is a fairly
>   seldom issue
>
> more elaborate approach
>
>   change \@pass@ptions so that it only removes spaces up front, around a comma
>   and at the end
>
> problem with the latter is that the current definition of \@pass@ptions is at
> the core of what LaTeX does, ie it is used by every package and any change in
> its behaviour might result in unexpected changes somewhere.
>
> so at the moement I'm a bit reluctant to make a change on the 2e-level for the
> sake of of one very specific case unless it is fairly minimal and appears to
> be "save". But I'm open to suggestions which is why I asked
>
> frank
>

The bug as I see it is that here the code not only removes the space but 
also the brace group around a single token. I assume you'd get the same with

   [ word {a} word ] => 'wordaword' not 'word{a}word'

which isn't as far as I know detailed.
--
Joseph Wright