I agree it would be nice to have some visualization of the change sets that fill the gap. However nothing can be done in 4.0.6 to support that. We released some pretty complicated changes of the internal workings of SCM in 5.0. These changes enable a few features, one of which was the ability to easily identify the change sets that fill the gap (which was also added for 5.0).

Also, the example you provided in steps 1-3 doesn't actually work like that in our SCM model. In step 2 for example, if we identified that CS38 depends on CS27 and CS29, (i.e. they are the change sets that fill the gap), then when trying to accept those we would not get another gap exception. They would just accept cleanly since those are the change sets in the gap, otherwise we would include 'all' the change sets in the gap. For example starting from the top, if you accepted CS42, then it really does depend on also accepting CS7, CS9, CS17, CS21, CS26, CS27, CS29 and CS38, since those are the change sets that fill the gap.

<continue reading below>

Also, the use case where the end goal is to reduce the merge effort sounds a little strange to me personally, or at least I have not heard of that request specifically.
Here's some of my thoughts on that:
In general, each change set tends to represent a different defect fix or new feature, and is often associated to a corresponding work item (Note: this is a little simplified for this example). So if you are accepting a change set in the effort to accept Feature X, a gap exception 'could' occur, allowing us (in 5.0) to see that it depends on other change sets, say Feature A, B and C and Defect Fix Y and Z. At this point, the common practice is to make an executive descision as to which other features or fixes we want to also be included in the accept or back / forward port. So if you only want Feature X, you cannot accept any of the change sets in the gap, otherwise you will also be bringing in Features A/B/C or Defect Fix Y/ Z. If you decide you also want to bring in all the other features and fixes too, then you can accept them all (and you will NOT get a gap exception).
<continue reading below>

The other more rare case would be to decide at that point you want Feature X and and a subset of the other stuff, say Feature C. Since you made the decision, it doesn't matter how complicated the merge is, it must be done... So you select what you want, choose to 'not' fill the gap, and continue merging in the Gap editor which was delivered in RTC 4.0.6. However we urge anyone who does fill the gap or cherry-picks from the change sets in the gap, to ask themselves why was the decision to accept or back/forward port those features / fixes was not done before hand (i.e why were they not in the initial selection in the first place?).

<continue reading below>

Also, the most common use case I've seen for completely filling the gap, would be cases in which the user wants to do something quick and temporary, without flowing those changes to any development/integration streams. Ex: If developerA wants to review a feature that developerB was doing, developerA can change the flow target of their repository workspace to developerB's repository workspace, they can then accept the change sets for that feature (or without changing flow targets, perhaps accept change sets directly from a work item). If there are gaps, they don't care what other features or fixes get brought in, they just want to accept everything so they can get in a state which they can compile everything and test out the feature they want to test, once they are done, they likely will discard all the change sets they brought in.