Hi Jos,
well, don't be too rash in chucking away the idea of profiles. After all, the UML folks have come up with the idea for good reason... I have used it fairly frequently and can't really say that I've had any trouble...
But first to your original question: really, to re-phrase... the bug/problem seems to be a lack of inheritance across a stereotype class hierarchy... I cannot believe this to be a feature, I'd file a bug report with Sparx. Although I can see a use for it, I haven't used it myself. However, I would wonder that having that many tagged values that you worry about "tagged value sharing" through inheritance, there's something a little odd happening... after all, these are "extension" mechanisms to the intrinsic UML constructs, supplementation if you like, and not a mechanism to define a new language in its own right.
Now, back to your comment of not using profiles... Consider however, that when using a profile, your modeler can easily drag and drop stereotypes onto model elements --- and pick up any (pre-defined) tagged values (with their own enum values, defaults, etc.), color schemes, icons, etc. Further, it let's one person in the organisation define such properties --- and have it enforced across the entire group. Profiles are exportable, and can be re-imported into other models. Yes, I have found the 'sync' feature rather spurious (although generally not a huge issue).
Secondly, and this is something that I've learned only recently, I now package everything as a "MDG Technology". These are bundles that not only package profiles, but "global" tagged values, images, code and model transformation templates, data types into one convenient whole. "Technologies" can be exported and re-imported into other modelers' repositories.
In the most basic example, it lets you work on your modeling standards (your profile, or your MDGTechnology) in a "sandpit" model, refine it ad lib. and then simply distribute it to all modelers and their respective models.
cheers,
-olaf.
