This is probably not so much a cut and dry topic. But, the overarching issue here is that many people use these tools in different ways. What one person may think is poor modeling using one paradigm, it could be considered good practice in another. The way for a tool like this to support many users is to provide the ability to configure the different default characteristics per type, stereotype, diagram, etc. If there were settings allowing you to override the default relationships that show up on a given type of diagram, this would meet the need I believe.
As for this being a modeling issue. I find that sometimes people operate too much at a "global" level. So, they define flows (dependencies) between classes/blocks instead of between properties/parts. If you want to say data flows between System1 and System2, that relationship would show up in all cases. What if you want to assert that in a certain situation, data does not flow, or a different type of data flows?
This is why I think modeling a Domain or other context element, then associating (composition/reference) the Classes/Systems provides some containment for your modeling into a specific context. I could have a System of Systems domain block, that has a composition relationship to System1 and System2. System1 and System2 are given a role.
Then, you could allocate behavior to sys1:System1 or sys2:System2, or define Flows between them, and then these relationships would not show up when you place System1 or System2 into a different diagram. Of course there will be cases where this doesn't make sense, but this is how I typically handle it.
