Now repeat the same with a set of packages where the Obsoletes tag
remains in one of the packages
OK so it is exactly like trying to fix the C code issue with left some parts of last changes iteration which should be fixed by deleted such lines completely and instead such deletion someone is implementing jump over such left part :)
This is not is not a solution ..
So exact paragraph in FPG should be not about using versioned Obsolete rule but should contain straight rule that "resurrecting" package should cause remove Obsolete rule as consequence such decision.
If it is still not clear will try to explain it on pure physics (thermodynamics) background.
Someone mistakes by living such Obsoletes rules should be not supported by FPG advice because this approach *increases packages internal entropy*. Adding Obsoletes rule increases such entropy (it enriches package description). As you know it is not possible to decrease entropy in isolated system without spending additional energy. Such energy should be spent precisely on *remove Obsolete rule* in last step of test scenario.
Or in energy terms: bringing back some package to full use must be done with remove Obsolete rule because it is lowest possible system energy state.
Or in plain form: someone mistake/error cannot be solved by leaving such error/mistake as-it-is and adding even more complicated wrapping rule which preserves such such mistake forever.
And last explanation pure on rpm background: every time when package like test-static is produced it carries not straight visable rule about obsoleting *all older versions of packages A-static*. Preserving explicit in spec file versioned Obsoletes rule *duplicates logic of internal rpm dependency resolver processed rules*. It is some possibility that in even more complicated cases which I cannot describe now such fixed/explicit in spec rule will cause another pathological case. Risk is small but still non-zero.
Let's try to think about our example test-static 3.0 package but without past. If leaving "Obsolete: test-static < 2.0-1" is correct it must cause that every other distribution <foo> package must have now "Obsolete: <foo> < <current_version>" as well. No one is using such approach!!! Nonsense .. isn't it?
Why bringing such example has sense here? Because what for some packages maintainers has past, for some packages "consumers" has no such past .. they are installing such package on fresh system.
As I proved to handle cases with and and without past is possible using specs with remove Obsolete line when package like test-static returns to life.
Q.E.D.
IMO .. case is closed.
Now I know why I had problem with understanding this scenario because leaving Obsolete line for me was and still is completely irrational so initially I've not been even thinking after more than 20 years of using rpm someone decided to use it incorrectly !!! :)