I would love to see that feature myself, but I don't think it's possible.
If an application takes a long time to start, there could be any number of things causing that:
- Whatever launched it could be slow to fork and execute it
- The filesystem could be slow to access the application's executable file (especially if, for example, it's a network filesystem)
- The application could be slow to initialize itself prior to connecting to the X server
- The application might be incurring a delay between connecting the the X11 server and opening its first top-level window.
What us users will think of as the time when we launched the application is really earlier than all of that. It would be the time when the mouse button was released causing the menu option for launching the application to be chosen. Or the time of the Enter keypress in the terminal that caused the shell to accept the command that caused the application to be launched. Or maybe even the time at which the browser hyperlink was clicked which caused a download which eventually caused the file to open when the download was finished. Whatever it is, the system isn't clever enough to causally link the event in question to the eventual display of a new top-level window.
I guess one could approximate the feature by considering the application launch time to be whenever it first connects to the X11 server. The X11 server can at least in principle know that easily. That would at least mitigate delays that occur after that point in time by making it possible to open the application's window on whichever workspace was displayed at that time. It would also require keeping a history of timestamps when workspace switches occurred so that one could go back and determine which workspace used to be visible at that time. That's a SMOP. It would be interesting, and I don't think it's been done, and I don't know how much work it would be, nor whether this approximation would be good enough in practice.