First oof, I'll poitn out that I'm not on the team, and so I posted how
I see things based on reading the various public pieces of information
and the code. I also took a "broad brush" approach: there are some
things that I did not mention.
> 1) Loosening of the 9-argument restriction on user-written macros: this is
> a thoroughly antequated and very limited restriction.
Two things here. First, keyval-type methods already do this, and to be
honest a macro which needs say 15 arguments in a row seems a bit
daunting to me! Second, the low level #1, #2, etc. business is from the
engine (no idea about LuaTeX).
> 2) Arguments to user macros resolved by #1, #2, etc.: See 1) above.
> There are many ways of refering to arguments and the
> #1 #2 etc is very limiting
> 3) Arguments specified positionally only: It should be possible to
> specify argument by name=value pairs.
Again, keyval-type methods do this, and allow you to store input as
named macros (which is pretty close to what you ask). The template
module does some of this, although I've made the case for a more general
keyval module with my "keys3" attempt.
> 4) User macros are local only, not global, not extended:
> The full command structure of TeX should be able to be
> specified by protected LaTeX macros. There should be a
> \newgcommand \newxcommand. For most, this is not
> important, but there are times that only a gdef will do.
Two things (again). The xparse module, for creating document commands,
probably answers some of this. Second, I get the feeling the the team
would like *users* to define things only in the preamble, and then only
simple things. Once you need things like \edef or \gdef, you are moving
to programming and I suspect should use either xparse or the internal
syntax (\def_new:Npn, \def_new:Npx, etc.).
> 5) Changing page dimensions in the middle of the document:
> Middlebach says this can't be done, but I have done it in
> my newlfm macro, and I say "rubbish" to Frank -
> it can be done, and it should be possible.
I always thought this was an engine issue. Shows you what I know!
> 6) Finally, something far more sensible on fonting needs implementation.
Like Will, I wonder what you mean here. If this is the loading fonts
business (particularly OTF with pdfTeX), I'm not sure the format can do
much. Of course, if LuaTeX was required from the word go, life would be
very different in that respect.