Thanks for responding, @modius --- this is a very useful start imho. Comments and further questions/items inline...
I think a lot of what you said above is very true and can be a starting point. But it raises a strong question re community involvement:
Why is LAS releasing a proposal outlines the expectations for the initial release but hasn't involved its community of (expected/targeted) users --- or involved only in a very tangential way?
The assumption here is that the foundations of the new language (and please note I'm clearly distinguishing this from the foundations of the architecture of Lucee 5) are being built and decided on behind closed doors of LAS (I assume by its members).
[If one wanted to take it in a malicious and negative way, one could well argue that this approach is not much better than the approach of a lot of commercial software companies that would throw an alpha at their users after having magically determined (= "marketing has guessed") the features people might or might not want in version x of the product.]
I'm not at all saying you'd not be entitled to do it this way, but I don't like it and I think it's the wrong way for Lucee. See my original post re open and transparent involvement and how I think it should be done instead of the status quo.
There we go - this is pretty much very close to a basic mission statement that I asked for in my post. Seen from a pragmatic point of view, that's not it though - right? In Lucee 1 you'd for instance change all tags from CFsomething to :something --- and I think even this decision needs to be looked at again. Decisions like Component vs Object and many more have pretty much been already made by @micstriit and others in LAS. Some of those decisions have been discussed by some interested folks on the public Lucee list, some others in this forum, some further ones probably haven't been discussed.
And I'm the last person saying that every little feature (change) has to be run by and discussed by every single person on Earth ever having used Railo or Lucee or ACF. However, this issue is that not even the big picture had been presented to anyone until pretty much now. Is there a strategy beyond
that anyone else but the core implementers of Lucee Language have worked on? Are there any architectural principles --- referring to the discussion about adding and abort-attribute to cfinclude and how do those get weighted against "pragmatic" (and sometimes bad practice coding) requests etc.
In reality we're not talking about a proposal for a Lucee Language that LAS is going to produce, but we're talking about an already quite involved and quite-ready first alpha or beta of the language.
And again - LAS is absolutely entitled to do whatever they want. However, the way how I currently see things going from a language evolvement point of view, the following applies:
a) Lucee is currently NOT a real community-driven project to me. It might allow interested users/community members to voice an opinion on some things that might or not be taken into consideration by the implementation team.
b) It at the very least seems that the majority of the language-/future-related decisions are made behind closed doors by the $-paying LAS membership.
Both a) and b) are fine and a valid approach to run thing provided they're communicated clearly, then everyone would be on the same page. Actually, I limit the statement re b) --- this approach is not ok because just by paying a membership fee one is not necessarily (or at all) qualified to decided on the future of a language or platform.
As long as those and other points are not sorted, this is much less of a community-driven project than LAS is trying to sell it as.