Re: how to estimate speed of a transformation

I am not asking for anything which is not here.

These technologies have been developed partially in parallel with
the spec but mostly afterwards. We will probably see more
improvements in the future.

The real question is: why should a language spec require a specific
processing model for a bunch of specific optimizations? It may turn
out this prevents some much more important optimizations later, which
wasn't obvious while the spec was created.

Wandering somewhat OT for this list: for the classic languages and
compilers, competition and market pressure market worked. If you
wanted to sell a compiler, or some hardware with a specific compiler,
you'd make damn sure that
- it will provide a benefit for the target group
- the competition would have a hard time to provide the same benefit.
Note that it's basically impossible to sell a C++ compiler nowadays
which doesn't implement for example constant folding or clever automatic
inlining, although the C++ spec doesn't mandate either of these.

OTOH, for any specific project/product there will always be limited
development capacity to implement every conceivable optimization at
once, so they have to pick some which they deem to the most profitable
(whether the profit is money or ego-boost or whatever).

Why don't you pay bick bucks to, say, the jd.xslt developers and
tell them to implement exactly the optimizations which make running
your style sheets ultra-fast?