KJ4IZW can step in here and provide more detail I'm sure (if he can see his way clear of the diapers), but as best as I can figure it out this looks like a consequence of a recent change in the ADIF standard.
At one time, most/all of the PSK variants were all defined as "Modes". So all of the following were valid:
Apparently eQSL was allowing the storage of all of these variants in their underlying database directly as MODE.
With recent changes in the ADIF standard (I think starting at v3.0.4), the only valid MODE for a PSK-type signal is PSK--all of the variants are now defined only as sub-modes. (There were similar changes to certain other digital modes.) So the entry for a PSK31 QSO should include:
Software and systems are allowed to accept the variants as modes for import purposes. But exports are now allowed only to be in the MODE (SUBMODE) format.
(Note: I really don't expect that eQSL actually uses ADIF as its storage protocol. But the storage should resolve to the new-standard ADIF for exports. eQSL probably had to choose between writing a utility that would modify its exports "on the fly" to meet the standard, or it had to modify all the database entries so that a simple export-to-ADIF would work. They apparently chose the latter approach.)
This required eQSL to modify any entries that still had PSK variants in the MODE field, and replace that with PSK (PSK31) [or similar] entries. Rather than unilaterally reviewing all 521,467,801 eQSL data entries (as of this moment), they are asking users to run the utility on their own log entries. That's the "pop-up" that Rick saw as he logged in to eQSL today.
I would guess that this transition of database entries (which phases in at random times defined by when users log in and run the conversion utility) could have other effects, perhaps being the reason for some of the issues users have seen recently.