I think the reasons for the limitation on the virtual desktop setting are more ideological than technical. It used to work the way you say, but then Wine's desktop management was overhauled so that: * Explorer.exe manages all desktop windows, including the virtual desktop. I believe this is required for multiple processes to exist in the same virtual desktop window. * Wine's virtual desktops now use the window station/desktop API's (which also exist on Windows). In theory, Windows programs can use this to inspect all of the available desktops, interact with windows on other desktops, and control the desktop window of child processes. But it also means programs on different desktops are isolated from each other unless they're programmed with desktops in mind. * Processes inherit desktops from parent processes rather than creating their own. This is technically necessary because of the previous point about isolating desktops. If a program spawns a child process that ends up in a different desktop, the child may not be able to communicate with the parent, and you end up with a Wine bug.
You could perhaps argue that the concept of a virtual desktop window and the win32 concept of a desktop should be separated, and it should be possible for a process to exist in a separate desktop window while being in the same win32 desktop as processes that exist in a root window. That sort of thing can currently happen when Wine is run from two different X sessions, such as a local desktop and remote X over ssh. Taking steam and some fullscreen game as an example, some weird things happen when the fullscreen game is on the same desktop as steam but its windows are in a virtual desktop. For one, the two processes don't see the same screen resolution. If the steam window gains focus, the fullscreen game necessarily loses focus (because only one process per desktop can be focused), and that may cause the fullscreen game to attempt to minimize itself.
The challenge of making this work is to come up with a system that is consistent, a correct implementation of the win32 api, enables the use case you want while not breaking anything that works now, and can be implemented cleanly. If you can manage all of those things, you can probably get your change into Wine, but it's a really hard problem and might not even be possible.