One other reason I haven't implemented the simple @rootfs solution that
you used is because it discriminates against users who converted their
Debian systems to Ubuntu and/or SUSE style subvolume layout.
What solutions have you thought of?
This is my first experiment with using btrfs in any capacity so I don't believe I have a good understanding of the btrfs features, use cases, and end user behavior to offer much analysis or suggestion as to how this might be handled in a better way for anything beyond how my expectations didn't hold true when using rescue mode. That expectation being that I'd have an easy way to get a root shell on my root filesystem. I was not even aware that the Debian installer would create a subvolume for the root filesystem during install until I found that launching the root shell failed.
I'm using LUKS, LVM and then btrfs under that so I am familiar with the menu for selecting the logical volume to use as a root filesystem. I didn't go back to confirm but I don't recall the list of options for the logical volume to use being filtered for only logical volumes that would make sense as a candidate for a root filesystem to mount. As a professional systems administrator I'd also prefer if Debian did not make decisions for me or if it does make decisions that those decisions do not exclude my ability to make alternative decisions instead in case it makes a mistake. So even though I have a rather large list of logical volumes to select from in rescue mode I don't mind and would like that not to change. One thing perhaps that would make sense (or maybe is even being done) is to order the list so the most likely/frequently used options are near the top and that ordering is performed on an analysis of root filesystem viability.
Given those considerations, the solution I see to improve the situation for myself isn't very complicated. I think it would be fine if the btrfs sub volumes were enumerated and a list of options was provided to me to select from and the chosen sub volume was used as the location to launch the shell. Other concerns notwithstanding I think it would make sense to continue to have the contents of /target be the btrfs volume mounted with no subvolume specified (continuing the behavior as it is now) and that when the menu is used to pick a subvolume it only tells the Debian installer what the chroot directory should be. I would prefer to not have the suggested filtering step that would remove options performed (as my interpretation goes for finding root filesystems with viable boot loaders) though an ordering step might be nice.
If there is only a single subvolume present I don't see why it would be necessary to prompt the user to select the only option from a list so I don't see why there would be an issue not offering the sub volume list in that scenario. Alternatively filtering the sub volumes could be made conditional with an option presented in the Debian installer rescue mode UI.
I guess the tl;dr here would be: not that I know much about what I'm talking about here but it seems a simple fix is available and not too difficult to implement and would improve the situation.
Please let me know if there's anything you'd like me to expound on as a user of this particular feature of the Debian installer. As well thank you for your consideration of the bug.
Cheers,
Tyler Riddle