What are the document/design interface layer plans for the LaTeX3 project?

Question

The LaTeX3 project website explains:

A while ago we made the decision to drop the idea of a separate LaTeX3 format that would exist in parallel to LaTeX2e, but instead decided to gradually modernize LaTeX to keep it competitive in today’s world while maintaining compatibility methods for older documents.

My understanding of the long term plans is that the kernel internals will over time be rewritten in expl3 and new features (e.g. native color and hyperlinking support) will be added bit by bit. What is rather unclear to me are the plans for adapting the interface and defaults for document authors and the degree to which backwards-incompatible changes are planned (or if this is even decided yet). For example:

• The recommended macro naming scheme, to my knowledge, is \snake_case/\snake_case_with_signature:Nn for programming layer macros, \CamelCase for package/kernel interface commands and \lowercase for document level commands. Since all of the LaTeX2e interface is in the \lowercase form, I assume that those macros will be aliased in the new \CamelCase convention (e.g. \UsePackage) and the old names will be kept as a deprecated alias? Or are there other plans?
• The expl3 manual acknowledges that many TeX primitives "have names that could be very useful as document mark-up tags were they not pre-empted as primitives (e.g. \box or \special)". Now that all of the primitives have expl3 aliases, their original names could in principle be reused for other things once the kernel is rewritten (as well as used packages). Is this considered an eventual feature, i.e. users / package authors should expect to be able to use those names, or will the use of these names remain "officially" discouraged indefinitely?
• One thing I have always been annoyed by is that environments and macros cannot have the same name due to the environment foo being implemented by the macros \foo and \endfoo. I realize that this was considered a feature when it was designed this way, but in my experience it is much more common to need different implementations for equivalent block and inline functionality than not, leading to the necessity for macro names like listinline. There may be other similarly unfortunate design decisions, though I am not aware of any. Are there plans to change such interfaces, in this case hiding the implementation of environments in macros like \env_foo_begin: and \env_foo_end:?
• The xtemplate manual mentions that "the standard LaTeX 2ε classes look somewhat dated now in terms of their visual design". Are there plans to modernize this default look, moving closer to what KOMA-Script or memoir offer (or even a different direction)?
• In this answer from 2013 Frank Mittelbach expresses an intention to move away from the template concept (back) towards a CSS-like LDB implementation. Is this still on the roadmap?
• Feel free to add more relevant comments.
• Is there a dedicated place where I can read about the current state of these plans? I have read many documents published by the LaTeX3 project but I find it challenging to keep an overview of what's where and what's outdated, especially since many of the documents outlining the goals of the project (like ltx3info.pdf) seem to predate the decision to not make it a new, separate format.

Answer 1

• "I assume that those macros will be aliased in the new \CamelCase convention"

  The conventions here haven't really changed. latex2e has always had \RequirePackage as the package level command with \usepackage being a document level alias for that. However commands in the preamble can reasonably be considered as document level or package level, and it's hard to avoid a mix there.

• "Now that all of the primitives have expl3 aliases, their original names could in principle be reused for other things"

  The original LaTeX3 format undefined all primitives, as does optex. I suspect that can't be done in 2e.

• "One thing I have always been annoyed by is that environments and macros cannot have the same name due to the environment"

  It would be possible in theory to make \begin and \end look for a different csname and use that if defined, but I don't think there are specific plans

• "Are there plans to modernize this default look"

  Probably can't change the look of article but probably newer classes will emerge (not just from the core team) that are written using these features, which may have different, more customisable designs

• "Is this still on the roadmap?"

  There are plans to do something....

• "Is there a dedicated place where I can read about the current state of these plans?"

  Almost all development happens in public on github. In practice current work is driven by the tagging project, which is described at https://www.latex-project.org/publications/indexbytopic/pdf/