I would say that you might want to look at any of the numerous tiling window managers out there that will facilitate what you are looking for. There is xmonad, awesome, qtile, dwm, etc that allow you to setup workspaces that correspond to your what application you are opening and open them there. I3 isn't as flexible as many of those and really isn't what you are wanting. The issue with that is, however, you will need to be able to program the config file to tell it how to do that. Two youtube/lbry people I watch that use tiling managers exclusively are odysee.com/@distrotube:2 or odysee.com/@brodierobertson:5 . I know distro tube has a gitlab repo that he has templates for all the tiling managers and has tons of videos for that. Unfortunately Moksha isn't really designed around workplaces as much as those system are and they already have, what I believe will solve some of your issues.
I've briefly looked at Sway, Openbox, awesome & dwm before and while each seems like something i might be happy with after the initial learning curve, none appear as flexible as Moksha. So, i would rather take my time figuring out the steps for reproducing the bugs that keep me from having a pleasant user experience with Moksha, rather than spending an equivalent amount of time setting up a less flexible tiling window manager i can't even make full use of since i can only comfortably fit roughly one terminal window or application on screen at a time anyways.
Even the basic Maximus functionality would get around basically all of my usability issues at once.
As to Moksha bugs mentioned such as the settings panel "that's often (randomly) missing it's window decorations (borders) thus requiring me to restart Moksha to to continue with configuration; similar thing also happens with 'Modules' & 'Shelves', etc." I have never observed this and can not duplicate it. Problems a developer can not duplicate are the hardest to debug, and may or may not actually be a problem. If you look at github and launchpad issues alot (Like I do) you will see many such issues dismissed by the developer(s). That can be frustrating if for example I am having THAT ISSUE and it was reported by someone else 2 or 3 years ago and dismissed by the developer because it was non-reproducible. So any such issue report in a separate thread. We may or may not get to the bottom of it but we are more likely to notice it if it is not buried in a wall of text and mentioned with a pile of other issues and suggestions.
It was always my intention to post proper bug reports on separate threads after having gathered enough information about the required steps for reproducing them. This thread only ended up getting sidetracked due to mentions of semi-related bugs (examples) getting more attention than the main subject did. I have now finished documenting the steps needed for reproducing the issue on my 1005P: Here