We have a lot of complexity in flutter/packages tests around reliance on published dependencies, which can bleed into flutter/flutter due to the analysis step that's run in flutter/flutter.

We had a recent case where we ran into a new variant, which could definitely happen again. The chain of events:

1. We deprecated a method in a platform interface package of a federated plugin
2. As expected, the flutter/packages CI flagged that this would break analysis in the higher-level packages that make up that plugin.
3. We updated the PR to include // ignore directives for those cases (which would then be cleaned up in the next PR).
4. We landed the PR, and the change was published
5. flutter/flutter started failing, because it's using a pinned version of flutter/packages, so instead of getting the ignores immediately and the published dependency later, it got the published dependency before it picked up the ignores via the flutter/packages->flutter/flutter roller.

I'm not sure yet how to best avoid this.

• We don't want do exact pinning in the package itself, because it's a published package's non-dev dependency.
• We could break things apart (like we used to) such that we update all the packages first, then deprecate the old method, but that's more overhead, and there's still no guarantee the ordering of that won't be wrong in flutter/flutter (although it would certainly be much less likely). And that doesn't work well for other similar cases that can cause analysis warnings, like adding an enum value.
• We could convert ranges to exact pins in flutter/flutter before running analysis. That does mean it would sometimes be analyzing with older versions of dependencies, but that might be fine since by definition the lowest version should work. It might cause conflicts though, by preventing the resolver from working normally.
• Maybe we could do something like the version-at-time script that some other combination tests use (customer tests, IIRC?), but for pub? So in flutter/flutter, for each direct dependency, we set the constraint to have a max of the newest version that had been published at the time of the pin?