Hi,
Well, it can always be discussed if it is an "accident of text editing". I came up with this comparing how the legacy tooling behaves when "emptying" the code snippet, which for the non-inheritance case removes the opaque behavior, and for the inheritance case leaves the opaque behavior, which in practice (from the perspective of the end-user) is redefining it with nothing, which basically is the same excluding.
Once again, the legacy tooling have never supported the explicit notion of excluding opaque behaviors. So there has in practice never been a need for it. The only need that has existed is to leave the code snippet empty, doing a redefinition of nothing (and the user has not even bothered that a true redefinition has been made either).
Of course there should be a visual feed-back, that the exclusion have happened, i.e. the icon on the effect/entry/exit tab should use the excluded decorator as one would expect. So the user would see on the tab whether the code snippet is left only redefined, e.g. if there are whitespaces left or if the user makes comments (in which case the user should get that commented code snippet should be included in the generated code as one would expect).
Since the code snippet view stills needs to be aware of the case of deleting the opaque behavior for the non-inheriting case, we could make this into the same as the combined delete/exclude buttons, i.e. the code snippet view should always "delete" the opaque behavior when it becomes empty, but for the inheritance case an exclusion should be made. So I don't see that the code snippet view really need to know about the exclusion case, since it should be possible for it to only know about a "delete" case.
I'm just sorry, that this proposal didn't appealed. Personally I liked it a lot when I came up with it, since it was so simple, and it was aligned with how the legacy tooling behaves.
Back to the drawing board then... :(
/Peter Cigéhn