Timequest constraints for a dynamically phase-shifted PLL

So I went back to take a long and hard look my assumptions and verify them against the .PNGs I posted. It turns out that my statement:

] ...the window is both opened and shifted, by these. The window's opening is much less than how rapidly c[11] changes so the hold time is actually more tightly constrained than it could.

...appears totally wrong w.r.t. to the opening of the window. It has nothing to do with the launching data and how fast it toggles. To avoid metastability, a window can only be opened if gating the latching clock explicitly or implicitly gating the clock by gating its data, neither of which I'm doing. If the latching clock is not gated, then the fitter may violate setup time by fitting erroneously close to the latching clock edge prior to the one being targeted, and therefore result in metastability. This may be acceptable in some cases e.g. such as a async RAM example in the Timequest User Guide, but is unacceptable for my needs.

So my current understanding (hope it's correct!) appears to be fairly congruent to what you we're getting at, de-em, so nice work following and understanding the thread - much appreciated.

As might be expected, the fitter figuratively explodes when trying to fit with a proper 3.333ns window, regardless of how much the window is shifted. This is because the intersection of solutions for 8 phase-shifted clocks with that clock period leave a theoretical maximum fitting window of 416.66 picoseconds - so good luck to me - LOL?.

Thanks to everyone who piped in.