Sadly, yes. A search of the archives didn't turn up exactly this scenario (a
real-world situation, at least as real as our world is), so here goes:

A managment class has the following parameters:
Versions Data Exists: 7
Versions Data Deleted: 3
Retain Extra Versions: 180
Retain Only Version: 90

In our example, let the file be backed up daily for 10 days, starting with day
1, to fully populate (and then some) the ADSM database and storage pools with
versions of this file. If I understand how this works, on day 10 I will have:

The active version, to which the above paramters do not apply
-and-
six inactive versions, which were created on days 4 through 9, and which are due
six inactive versions, which were created on days 4 through 9, and which are due
to expire on days 184 through 189.
(And as a side note, the versions created on days 1 through 3 are have already
expired.)

Then, on day 11, the file is deleted and a full incremental is run.

On the next expiration, the Versions Data Deleted kicks in and deletes the
versions from days 4 through 8 immediately.

Does this then leave me with:
The version from day 10, which was the active version and gets the Retain Only
Version parameter applied to it, which would imply that it will expire on day
101
-and-
The versions from days 8 and 9, which already had their "inactive" clocks
The versions from days 8 and 9, which already had their "inactive" clocks
ticking before the file was deleted, still exist because they meet the Versions
Data Deleted criteria, and are scheduled to expire on days 188 and 189. (?!?!)

If I follow how these parameters interrelate (or don't), this scenario makes it
possible to have one or more files around that are older inactive versions even
after the file that was the last active version (before deletion on the client
host) is gone from ADSM.

Is this how it really works? If not, can someone point out the error of my ways,
and I will gladly repent, go forth and retain no more (or at least no more than
I have to).

Thanks for the enlightenment.
Regards, Steven
Steven Chaba, Lead Analyst
ADSM/AIX/HACMP (What more could you ask for?) Admin
Rochester Gas & Electric
Rochester, NY