> For a more extreme case, there is a schroot (or a docker container) with /home, audio and X mapped in. Works surprisingly well for desktop apps, like those embedded IDEs which require a specific Linux distribution you don’t want to run. You do have manage desktop integration (menu items, file associations) yourself though.

Very early Bedrock Linux prototypes were exactly this; including the choice of schroot. Bedrock could be correctly described as taking this idea and running with it, trying to stomp out as many of the "you do have to"'s and "except"'s as it can.

> Those solutions are hard to set up than bedrock, but they also do not have special filesystem magic,

I think a fair description of the trade-off between Bedrock and the two alternatives you've laid out should mention the breadth of functionality Bedrock offers they do not. This includes but is not limited to:

- Shell tab completion. For example, Debian's zsh can tab-complete Arch Linux's pacman

- Init systems. For example, one could run Void Linux's runit init, install Arch Linux's systemd, and reboot into systemd.

- Kernels. One could run Arch's kernel, install Debian's, update the bootloader configuration, reboot, and select Debian's kernel.

et al.

I expect, if you think about it long enough, you could see some ways schroot with things like /home mapped in could be extended to cover those use cases. If you pursue those, you'd end up recreating Bedrock.

> so I bet they are much easier to debug.

I am doubtful any user which understands setup schroot you described, who also takes the time to familiarize himself or herself with Bedrock, would have comparative difficult debugging a Bedrock system.