Scott had a concern about:

1. User is on 4.y.old in the *-4.y channel.
2. User updates to 4.y.new, which happens to be a dead-end, without updates to 4.(y+).
3. User wishes to update to 4.y+, but because of OTA-694, 4.y.new is being withheld from the *-4.y+ channels, and the *-4.y+ channels are not available as options.

Instead, we could teach Cincinnati about dead-end prevention, and we could have the dead-end 4.y.new nodes go into channels, but withhold the update recommendations.  Using the history from OTA-743:

1. Current update recommendations are:
   1. A.1 -> A.2
   2. A.1 -> A.3
   3. A.2 -> A.3
   4. A.2 -> B.1
   5. But no update recommendation from A.1 to B.1, because A.1 is missing a pre-update guard that was added in A.2.
   6. And no update recommendation from A.3 to B.1, because A.3 includes a newer fix, which would regress when updating to B.1.

We're currently holding A.3 out of the B channel, because it doesn't have a path to B.2.  With this RFE, A.3 would be in the B channels (to allow folks on A.3 to select B channels), but without recommended updates from A.1 or A.2 (to avoid feeding folks already on B channels into the A.3 dead-end).