Surely one could select these from the family / other axes I defined?The problem is that the axes that you defined is not the only possible solution, and font foundries and designers may orginise the features in a different way. Indeed, one of your axis is "features", ¿what if we have non-exclusive features? You can always keep adding axis, but then you get an exponential growth of possible combiantions, that for most if not all individual families don't exist.
(outline, shaded, trafficlike (what do you mean by that by-the-way?
In a dangerous bend'' sign?) would go under family,
I mean this:
Roozbeh Pournader (from Iran), Feb. 2001:

We also do not have equivalents of serif and sans-serif, there are fonts
that have few details, using simple curves. They are usually called
"Traffic"-like ("Traffic" is a font family itself, so that's somehow
like saying "helvetica"-like, and is usually used for text on traffic
signs). But we can't classify them according to this, because there is a
spectrum between traffic for example, and things like "Lotus" and
"Linotron" that are equivalents of serif fonts and are used widely for
normal text.This also illustrates how open the problem is. Your set of axis is very complete for a latin script, but an iranic font plays havoc on it.

Surely one could select these from the family / other axes I defined? [...]
proportionalfigures was a part of one of the things which I described)Yes, I took it from there, and yes we can take the features form yours and others' lists. What I propose is not to associate each particular feature to a particular axis. think for example about an outlined variant of a font. Imagine that you draw the outlines with a thick pen, then you get a bold outlined variant. So if you type \bold\outline, such a family will select its bold-outlined variant, while other may treat the bold and outline features as mutualy exclusive, and many others may simply issiue a warning and continue. Think for example about Zapf Chancery or a Pifont, what sense does it have for those fonts to worry about outlined, shaded, expanded, or whatever features?, and...

I dunno. I think it's better to have an option to have them be
persistent _unless_ over-ridden.
...this can easily be done by providing a command \InitializeFeatures, to be placed in each font definition file right after declaring the family, which simply defines every feature to issue a warning. Form example, for the fd-file for the times family the \InitializeFeatures command would define a bunch of commands like

\def\times/outline{You asked for the font features "outline". This feature is not provided by the times family.}

When I said  "We let those commands to be defined by the family" I didn't mean "the meaning of the command to be interpreted by the families". If a family has oldstyle figures, then \oldstyle sould always produce oldstyle figures, but the family decides how it handles the feature \oldstyle in conection with its axis and the other features.

Say I'm typesetting a running head
and introduce a bit of text in a code'' style. I'd liefer have the
numbers be proportional oldstyle (say) [...]The problem is that proportinal oldstyle figures may not be provided by the font, or, which is the crux of the matter, that the different sets of available combinations (and hence also differnt substitution decisions) may vary widely. The font may have oldstyle figures, but it may just have them for the normal roman variant and the bold one. You may try to give a (possibly correct) answer to this particular problem, but you cannot give an answer to every potential situation. The problem is that the way the available features for a family are assigned to particular axis, within each one each of the features is mutually exclusive with the others, may vary widely (and with it the substitution-warning-error model). So my point of view is that we better let each family define its own axis-features model, while still imposing fixed names to particular features (\outline, \bold, \condensed, \trafficlike, ...), so that m
acros that make use of those features will always work (and produce the expected results) if the the font used provides those features.

This does not mean than mamy families would not have the familiar shape/width/weight axis. for example, cmr could store those values in

\cmr/shape   \cmr/width   \cmr/axis

in a way similar to the current NFSS, but for other families with more artistic variants and combinations of them available the shape axis could be split into two or three. Also commands like \DeclareFontAxis and others (\DeclareAxisFeature{<feature>}{<axis>} ...) could be provided. So many families could build their fd-file with the facilities porvided by Latex commands, while still allowing any LaTeXpert font-expert programer to draw it font definition file for his high quality multi-variants fonts in its own personal way.

Finally, I would like to insist in that I am pretty persuaded that a closed set of fixed axis will always leave unsolved problems. Not only because of my thinking about this particular subject, but also for some other more general reasons, taken from other experiences, where once and again it was said that the new set of X would definitely solve the problem. Look at the following cite taken from the TeXbook:

... An 8-bit set was considered but the need for more than 128 codes in general applications was not yet evident. --- ASA subcommitee X3.2, American Standard Code for Information Interchange (1963).

Then 8 bits was enough, then 64 (Unicode), then ... No, I think a fixed set of axis, even one for each script, will always be a problem in the future, and also in the present. I found myself as a programer deciding that my simple fixed hardwired model was fine, since "I will never need any different", and always found myself, months or few years later, redoing my model to extend it. Now I try to avoid harwired values as many as possible.

Javier A.