Feature Request: Cube option for separate Workspaces by display/screen

I realize this has been suggested long ago, and there were reasons it would be difficult, but I'd like for everyone to take a fresh look at this and see if it might be doable.

Currently, I use Compiz on Debian with MATE and Emerald. I also use Nitrogen to paint the different screens with different backgrounds, so I know it is possible to do things different per screen. I realize this could be confusing in the task manager (for MATE) and Workspace switcher, or whatever Desktop Environment Compiz runs under, but couldn't we just update what shows based on the current state?

For example, if a 2nd screen switched, then just update the workspace switcher and task bar with the new currently visible windows. On the back end, it would be like we create a virtual workspace and move windows in and out of it based on the ones presented to the user.

I've worked around this for years by making a few windows sticky, but it is kinda clunky for some cases.

Some considerations:

1. Allow an option for independent screen workspace switching, kinda like Mac does.
2. Allow dividing a single screen as if it is separate. I can kind of do this today by going into General Options -> Display Settings -> Uncheck "Detect Outputs" and under "Outputs", manually put in one of my screens twice with half of the screens pixels in each. This even allows for each half to rotate as cubes. Now if only I could get one to rotate separately...
3. Consider keyboard shortcuts for each display so you can rotate a non-focused one.
4. Consider if sticky fullscreen windows should just not rotate that screen. This one may be doable without much change, but is also not needed if you do the others. I present it as food for thought.
5. Build in Nitrogen-like functionality to paint different backgrounds.

Feedback is welcome. If there is a lack of bandwidth or priority for this feature request, then please at least point me in the right direction to hit the ground running, or shoot me down before I waste time. Specifically:

1. Can this be done? If not, why not? Are you sure?
2. Do you have any onboarding documentation or build instructions?
3. Any suggestions or advice on where to look?
4. Any advice to prevent common pitfalls?
5. I know this question is subjective, but...
6. How hard is setting up a safe dev environment without breaking my system?
7. How long does a build take on a local machine with 8 cores and pleanty of memory?
8. What does the dev workflow look like?
9. What are the expectations for pull requests? Squashed commits? Branch merge vs rebase? Or is that handled by GitLab and I don't have to worry about many small commits?

Thanks!

Steve