This is a known limitation, and it has as much to do with the -system-
menu creation processes (in linux, specifically the WM used) as it does
with cxg. The same situation arises if one installs the same app(s) into
a pure wine installation ... everything centers back to your $HOMEDIR,
and how the win32 app expects to present things to the user...
...I doubt you've picked a good example ; no app should -need- adobe reader,
it should default to using your system's .pdf viewer (kpdf, xpdf or such)
instead -- I do this all the time with gog.com games ; most of them want
to install foxit pdf viewer or whatever, I never install it, and when I
use a menu/shortcut to call the game's documentation, my system mimetype
association throws that call to the native pdf viewer installation...
...I have 3 Steam installations in my bottledir ; and although I admit it's
a tad convoluted (having to go back and delete/recreate menu entries some
of the time), it does work ... for example, I have X3:TC in it's own Steam
bottle -- doing that will present me with shortcuts to both X3:TC and the
Steam client therein. When doing that, I had to go into the menu editor for
the other Steam bottle (to recreate the Steam link/launcher), so that I can
launch that Steam ; the X3:TC desktop icon/launcher is left as is, for it
will use the Steam client in it's bottle...
..I very rarely use my normal user account for what you describe ; if something
gets trashed, I don't appreciate having to fix the user account I use normally,
so I always use a separate user account to test things & set it up -- once I'm
happy (and know what's needed/going to happen), then I will install into my own
user account...and I treat wine pure the same way btw....
..this all said, I do know the menu handling/creation process in crossover is
being looked at presently to see if there's a better way of dealing with things.
Afaik, gnome3 has prompted that rethink due to the fact the cxg menus get sprayed
due to changes in that WM (fortunately I don't use gnome, never will =) In many
cases, the win32 app's idea of what should happen is as much to blame for this as
anything else...ie; it is inconsiderate of the case of having a single user account
with access to multiple C: drives ; in windows, everything converges back to those
M$ places like 'My Pictures', 'My Documents' ... blablablah ...
..I have the same trouble with crosstie profiles, and I actually asked for some way
to delete menu items the win32 installer creates, so the crosstie can fashion it's
own links (which will work), but I've no idea if I'll get what I asked for <grin>
I only mention this, because in the case of many crosstie profiles, that much would
avoid the collisions you highlight ...but... I'm being somewhat preemptive here, as
the crosstie system doesn't yet handle Steam apps. The OSX menu handling is a bit
better in these regards...ie; if you install multiple Steam clients (bottles named
Steam, Steam2, Steam3 etc etc), then the apps associated with those bottles retain
their 'identity'...ie; the menu would display 'X3:TC (Steam)', X3:TC (Steam2) ...or
Steam (Steam), Steam (Steam2) and so on an so forth, and thus it's easier to discern
what's what...(which is analogous to what you describe)...
...I do feel everyone agrees on the fact that menu/desktop launcher handling could be
better, but I can't see any 'easy' way out of what's involved here -- I do reiterate
however that if crossties could delete/suppress menu/desktop links created by the win32
app installer, a good deal of this could be cleaned up -- the -real- problem is that
crossover (and the win32 app) will have no idea if you've got multiple Steam bottles or
multiple installations of the same app (and this includes wine pure if installed), without
a whole heap of extra logic to check for such a situation....