Thanks, there have been some scattered discussions of this but nothing that pulls them all together.
One of the things I've wondered about SequencedCollection is how much users benefit from having a common interface declared vs. just adding getFirst(), getLast(), etc. to the types where it could be useful. I haven't tried to dig up design discussions about this, so if you know of any, or if you have some experience in practice with this, I'd be very interested.
To actually answer your question: My guess is that we wouldn't introduce another flavor of Guava, given the complexities to us and to users of having even two. (Beyond the Maven confusion, I wonder if a flavor with an additional supertype for ImmutableSet would be relatively more likely to lead to source incompatibilities for users who switch between the two flavors of Guava. It's probably not going to come up much?) Or at least we'd want to accumulate a bunch of reasons (perhaps including SequencedCollection) to convince ourselves that it will pay off. It's not like it's totally out of the question, especially if the only changes we needed to make were trivial and automatable, as they could be here.
(An alternative that users have raised before is
multi-release jars. However, as you may already be aware, those are intended only for the case in which the APIs match exactly. And when the APIs don't match, we've seen
problems.)
Even today, we probably could getFirst(), getLast(), etc. to ImmutableSet and friends without implementing the interface. In fact, we did that, at least for ImmutableSortedSet (because doing so addressed another problem we'd encountered). However, we found that this could cause problems for Android users in some cases, so we
rolled it back. Additionally, we later discovered that, if we'd build Guava with JDK 21+, then the resulting jar wouldn't have worked with older JDKs. (Ideally, we'd
build with --release 8, but that's a whole project of its own....)
There's also the fact that we might complicate
building Guava with older JDKs. (Compare
#6549.) But we could probably work that out with enough clever Maven setup.
Do you want to open an issue to track this? Even if I'm guessing that we ultimately won't do it, it would be good to accumulate the possible reasons for doing so and also the possible obstacles.