Seems like if the foundry has control over the multi-patterning, and their choices impact the margins, then the only sane solution is for them to expose the rule deck.
Yes you can work around it but then you are adding slack to your design if you have uncertainty on what the actual pattern will be and so need margins in multiple places, only some of which will actually be needed. As if things were not tight enough already...
Would this be an advantage for the few, like Samsung or Intel, with their own fabs (or others with privileged relations to a fab) and rules completely integrated into their tool sets?
Corners can be used to check that a design performs to speed under a variety of production and use variations whilst not exhibiting nasty side-effects - for instance steps that might speed up a design might also risk shoot-through on short paths. Statistical analysis can look a little deeper to look for bad scenarios that happen away from the extreme corners.
But the problem with multi-patterning is that the errors are highly correlated ie all copies of a given geometry might be shifted to the left and hence all of those nodes might have an increased capacitance whereas all copies of another node might have lowered capacitance (assuming all the cells coloured the same way). This may introduce a bad skew particularly if one node is a clock and the other a critical signal that it gates. Alternately every copy of a given cell might be coloured independently (if the EDA tool allows this) and hence some nodes will be faster and some slower. Corners don't really model this.
Worst of all is for two cells that are meant to be matched (eg analogue cells, sense amps etc) but in the colourings are the opposite of each other, this will mean that a mask offset will have opposite effects in the two cells and hence cause a big mismatch. Again just using corners will not spot this, and using monte carlo simulation will only spot a sensitivity to the possibility of this happening rather than the certainty caused by a colouring mismatch.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...