Concerns
I've bothered few TC39 / standards-writing related folks and the main concern about this proposal seems to be the parsing effort from adopting engines: "too much look-ahead needed".
Somebody proposed a special operator to signal ESX, and @<esx /> among others might just fit the bill, but among all missing operators I couldn't find anything able to meaningfully contains ESX chunks.
<!><esx /></!> might be one, or to simulate a template:
<`><esx /></`>
might be another, where I am specially keen to latter proposal as it takes templating semantics ouf of current literals, and it surely doesn't break ESX by any mean, as a node called like a backtick won't likely ever be needed or happen out there.
While these proposal are still better than requiring mandatory tools to fragment what is JSX these days even further, I wonder why, if E4X was possible at some point in time, JSX like syntax would be that problematic.
The current specs say that any upper-cased Component should be a well known reference component in the scope, while everything else can be considered an element, or a fragment, so that the look-ahead issue seems to me not a blocker: is the reference lowercase? it's an element ... it's the reference capitalized as known function in thew scope? It's a component. Is it not known in the scope? It's a thrown error.
I am sure I am simplifying constraints around ESX but I think the DX developers want is pretty much exactly the same they have already via tooling and transformers, so that if a transformer/transpiler can do that, maybe JS could do that in core too?
Hoping to hear back from any of you about these concerns, as this proposal is kinda revolutionary but beside the Twitter space is going nowhere already, which makes me (and many other developers) sad.
P.S. mandatory tooling is cursing JS as PL because every transformer has different meanings, even around interpolation or ternary operations (solid-js) ... having a standard core/ground to define new libraries seems to be a great way to avoid fragmentation already existing around the JS ecosystem.