Uhm, interesting Fabien.

It looks really good thinking about how to advance versions, just in terms of how tests have to evolve. Really interesting, because it can apply to any other case. Maybe is missing the case for patch, but those are regression tests. So... it can possibly be handled automatically.

But, for versioning, I would say that all that is necessary it just is the major version. If a service improves the minor version, it will not affect me, it has more functionalities that I will not use. So, instead of having /v3.1/resource, and /v3.2/resource, just /v3/resource is enough. I discovered it almost a decade ago with the Apigee presentation Teach a Dog to REST (slides, video).

Unfortunately, as you say, most developers do not plan to provide support for multiple versions at the same time. It is hard, but often not so hard.

However, the big problem, is that it does not matter how many tests you add, that, if you are not careful enough, holes appear in your testing. Exactly like a 100% of code coverage does not ensure the absence of bugs, a bug, an undocumented functionality, or just, a weird case that we did not plan is supporting the consumer code. It can be as simple as in the first implementation, the order of the output is by id —yet, it does not have test because it is not a specified functionality—, but in a later version, an optimization changes it, and the consumer, who expected that, breaks. I know, it shouldn't happen, but often developers just try things and do assumptions where we do not expect them. That is something that we cannot cover with producer-driven contract testing because we cannot foresee all the infinite possibilities.

Sorry for this last point :/, but it's something I learned the hard way.
(But the idea about testing is cool… I’m still thinking about it)