If you really need full control over the app and to not use the normal routines through the site and admin apps, it is possible (I'd even say encouraged) to build your own web application baseline and use that versus trying to rely on the site or admin apps to be a one size fits all solution. This is exactly why the downloads site API is a custom web application class and not hooked into the site application using com_ajax or plugin events as the request handlers.

Long and short, everything you want is already part of the API. Some things do need some tweaking to better support having more than the two default apps (i.e. hardcoded app lists in places like the module or language managers), but Joomla is built as a multi application system already with the existing default applications being suitable for a wide variety of uses but explicitly not designed to do everything.

With all that said, I don't know what it is you're looking for here. Because to do the things you are aiming for means implementing new web application classes, not changing the existing web applications to have what becomes too complex of a set of code paths to efficiently follow and maintain.

As I detailed in the introduction, there are other indirect ways to do it. The main idea of the RFC is supporting the new use cases of the web technology in Joomla.

If the general vision is to limit the use cases to the currently supported ones (regardless of the new features supported by mobile and desktop browsers), then yes, there is no need to modify the current implementation.

How are we limiting the use cases though? Because I don't think it's a good idea to code a lot of switch conditionals into the application's execution path to act differently based on a query parameter?

App Domain: Most Apps currently live in its domain (or subdirectory).

As distributed Joomla is not domain aware, and inherently is not single domain or supportive of multi-domain builds out-of-the-box. This is functionality made available through extensions if you need multi-domain support.

Routing: Beyond the association of the domain-app, the app has a single view.

Joomla has several routing systems already at the PHP level. By my count in 4.0 there are three available options (the "classic" component routers or one of the two major versions of the Framework router package). Each has their pros and cons and requires a varying degree of configuration in your PHP code, and depending on where you're integrating into the system the UI (component routers hook into the menu manager already, other routers if you wanted a UI configuration would require it to be written).

Views: The application is implemented by an extension (template or component).

Views are format specific (i.e. XML, JSON, HTML, I'll even go so far as to say the controversial AMP format here). Views should not be domain specific (i.e. app, site, admin). IMO this notion is invalid.

Assets: All scripts, images, headers, meta, etc are declared to be rendered by AppDocument.

This can already be achieved by leaving out the head renderer in an HTML document, or by manipulating the document data at any point up to and before the rendering of the head element (i.e. the onBeforeCompileHead plugin event) at the expense of not being aware of any assets enqueued for loading by non-template elements. The part of this you do not have control over is inline content from a component or module without parsing the rendered string element, that issue will always exist as long as users are capable of inserting HTML through the UI.

Manifest and Service Workers: The App will have full control of the Manifest and Service Workers in its domain/subdirectory.

There is already an effort to support PWA, Service Worker, and every other buzzword going around right now. I suggest you join in that group to understand what they are working on.

Minification: The App is already optimised. As a nice-to-have, the CMS could concatenate all scripts that share the same attributes and are loaded sequentially.

IMO this should be a template level responsibility and is very highly coupled with the asset management proposal (to have concatenated "optimized" resources means the template has to be aware of all resources that can be loaded on all paths to either serve per-page optimized files or have one source). Some of this is also potentially a step backwards if you consider HTTP/2 asset preloading, critical asset paths, or other current web development trends.

REST Api: Yes, it is necessary, but beyond the scope of this rfc.

Already a work in progress, as you are aware of being a mentor for GSoC last year.

Plugins and Modules. They are App oriented. The CMS could load and execute plugins and modules associated with the App group.

Plugins are by design NOT app oriented. A plugin is a general event listener, it is therefore the plugin's responsibility to check the context to determine if it applies in that context and act or do nothing. This is in part what makes plugins so powerful, they decide for themselves whether they apply in a context and can choose different code paths based on that context (i.e. support for onContentPrepare across multiple components where they may parse a data source and transform it for HTML output or remove a placeholder like {loadmodule mod_login} for non-HTML output).

Modules are already application oriented, in the definition of an application that we use for Joomla (i.e. site/admin).

Event System, Yes, the CMS must follow the regular initialization. (The problem today is that components render the view and kill the rest lifecycle to avoid the output).

The event system is fine. The Joomla ecosystem is the problem. In core, and in extensions, we treat HTML output as a first class citizen and all non-HTML output as second class. To avoid plugins breaking things, there are commonly accepted code practices of early aborting the application so certain events do not fire, or just not firing some events at all outside HTML views. #14176 already covers this at a high level.

Multi-App: In this scenario, Joomla can host more than one App.

Again, Joomla is multi-application friendly, in what Joomla defines as an application. You seem to be proposing a new definition for the word "application" that collides with already existing terminology, infrastructure, and/or concepts. To better explain what it is you are seeking you should perhaps use an alternative term that does not collide with existing terminology, infrastructure, and/or concepts.

==========

I am not seeing what issues you are raising that are not already addressable with the existing Joomla API. Some efforts are in progress, some efforts require changes in the core code not started, some efforts require changes in the extension ecosystem.

The use case that I'm referring to is an extension that installs a Web App in Joomla.

When the user accesses the App, in the frontend or in the backend, the Web App provides a full-screen user interface. At any time, the user can go back to the regular mode.

The Web App must have an Html view completely independent of the current Bootstrap, JQuery, stuff. Something, that's impossible today.

If you think that it is better to introduce a JApplicationWebApp, sure, it can be a valid alternative.

So, the question remains, how Joomla can still be multi-application friendly, without adding the output of other extensions in the "App Mode".

The Web App must have an Html view completely independent of the current Bootstrap, JQuery, stuff. Something, that's impossible today.

But J4 will not have either Booscrap (js) or jQuery. Bootstrap Css still remains a huge problem weighting 250kb...

The Web App must have an Html view completely independent of the current Bootstrap, JQuery, stuff. Something, that's impossible today.

It's only impossible because extension layouts are coded to be dependent on these things. https://github.com/joomla-projects/help-proxy should still be installable (if not, the code is at least reviewable). Show me where the extension or template have dependencies to Bootstrap, jQuery, etc.

For the longest time, Joomla HAS NOT had ANY arbitrary dependencies. All UI related dependencies have rightfully been delegated to a layer that handles UI rendering (layouts, component views, JHtml helpers).

So yes, the core templates are built with a Bootstrap dependency. But if you need framework-less output, or JavaScript free output, it is entirely possible to do so if you build the infrastructure correctly.

Looks to me that all the questions have been answered and there is nothing to do here