Joseph Wright writes:

 > I guess I see a difference between 'being able to add things' and
 > 'having to add things'. Packages such as fontenc, caption and microtype
 > provide functionality that, in my opinion, should be in the kernel. (I
 > favour a much more ConTeXt-like coverage of 'official' material, as you
 > know.)

oh I guess we are in agreement here, eg a font handling mechanism belongs to
the kernel (as it is with 2e) a float handling mechanism belongs to the kernel
(as it is with 2e only that the one from the kernel is fairly primitive so
that people wrote up alternatives such as caption) etc. And microtype came long
after  the 2e kernel was frozen. Anyway, I still maintain that it is better to
have a frozen kernel and documents that say they use microtype or xyz then to
have a kernel which is a moving target and changes functionality from one day
to the next (which is precisely what happened in the last years of 2.09 prior
to 2e providing a new and bigger kernel and a mechanism to clearly extend (but
document) functionality.

So yes. I want us to include everything that we feel is "core" eventually (!)
in the kernel for latex3, but to build (and freeze) that kernel only when we
are ready for it and have a uniform interface.

And this is why xor, xgalley, xcoffins etc do not yet should go into it while
we are still experimenting with interfaces and ideas for those specific parts
even though eventually they will all become pare of the kernel
functionality. For example, the coffins ideas got several big rewrites and
only now are ready or close to ready to be added to expl3 (and later to a more
monolithic kernel.

For the same reason I think that it was probably a mistake to even start on a
small scale with adding something like l3font to expl3 --- as we have seen
even the few commands in there underwent some serious changes as this clearly
shows that we are far from ready here (and the same is probably true for the
luatex support so far as again those haven't been thought through to more
final conclusions and having them as xpackages for now wouldn't hurt at all
(even though it means loading such code seperately) --- the advantage is that
there is a clear distinction between experimental but fairly final code and
really experimental code).

cheers
frank

 > -- 
 > Joseph Wright
 >