Does any documentation about running nested mutter/gnome-shell exist?

I want to run isolated containerized DE inside main system using distrobox (something like lite VM, but with full GPU performance). And the main issue that’s too little information about how to run nested mutter/gnome-shell. I found only one env variable to change resolution/refresh rate MUTTER_DEBUG_DUMMY_MODE_SPECS. But no information how to add more displays (multimon config), run without window title, run fullscreen mutter. All other documentation about nested mutter will be good. As example, what exact key/mouse sequences are handled by host wayland and what by nested? is it possible to configure this behavior?

I found some more variables like MUTTER_DEBUG_NUM_DUMMY_MONITORS and MUTTER_DEBUG_DUMMY_MONITOR_SCALES but how to specify different resolution for the each monitor, because something like MUTTER_DEBUG_DUMMY_MODE_SPECS="1920x1080@120.0,1920x1000@60.0" doesn’t work :disappointed:

The nested backend is really only meant for debugging, and can’t be manipulated to be a isolated containerized DE running on some other host compositor. You are right that it doesn’t really handle hotplugging etc. It’s using part of the X11 backend, and doesn’t support a bunch of other things, e.g. virtual monitors, remote control, etc. I wouldn’t recommend using it for any “production” use cases.

I understand that it can work unstable. But still does any official documentation exist?
Running isolated desktop environment isn’t too rare thing. Usually it’s done using VM. But containerization is much more performant and more flexible.
I can use without any issues any wlroots based DE, but the main issue that these DEs have a poor design and don’t have even basic parts of DE (normal task bar/tray/etc)

There isn’t much (or any) documentation of how to run nested, as it’s primarily a developer tool. Arguable one should document developer tools too, but that is another topic.

Either way, GNOME Shell isn’t meant to run as an “app” in another system, it’s meant to be the session compositor. You can still achieve this (to some degree) while using a container, but it means you don’t have a host compositor that you wrap everything in, as GNOME Shell would talk directly to the hardware, via a “hole” in the container.