Is your feature request related to a problem? Please describe.
We just had a user report a script ran too long error on the login thread in #4911. Turned out that user had a SavedVariables file nearly 40MB large, representing nearly 6k installed auras. A good 30-40% of those auras were:

• intended for past content seasons & thus entirely useless today
• not marked in such a way that rendered them "unloaded" (this is probably not realistic to expect of authors at the moment)

Describe the solution you'd like

WeakAuras should know (how?) what season it is currently, and also know (via a load condition? metadata the user isn't privy to normally?) what season an aura was 'created' in. When the user logs into the new season, they should be prompted to do some spring cleaning. Obviously nobody will bother to do this, but we could at least try. Bonus points if we can also interpret "aura is intended for different season than current one" as making the aura impossible to load.
No, I don't know what this would look like for classic. Stop looking at me like that, buds. Perhaps instead of seasons, we would just do this on expansion change? who knows.

also know (via a load condition? metadata the user isn't privy to normally?) what season an aura was 'created' in

EncounterJournal make it possible to list current season dungeons & last raid encounter ids
It is possible to mark all auras and their parents that load on old encounter ids with Private.AuraWarnings.UpdateWarning(data.uid, "old_content", "warning", L["Aura made for old content, consider cleaning unused auras as trying to save too much data may lead to a critical loss of your aura collection."]) with an icon flashy enough for users to care about getting them out of their list

I don't know what this would look like for classic

There is no EncounterJournal on classic (yet, i think it's coming for cata), but we handcraft a list of relevant encounter ids for the tooltip of this load option

Would it be a bad idea to measure time that login thread takes and if it takes more than for example 15s you notify users that their SavedVariables is close to being oversized?

EncounterJournal make it possible to list current season dungeons & last raid encounter ids

I have a working implementation of this idea, it use a list of all encounter ids from current season and current expansion build from EncounterJournal
Only issue is that it will warn as outdated content auras with an encounter load option made for previous seasons

implementation: mrbuds@bdeca38

ok, so possible workaround; in information tab, if "old content" warning is set, add a checkbox to suppress. User can opt in to having huge SV without us complaining & effectively restore previous behavior? or is this just a complex way of doing nothing?

Would it be a bad idea to measure time that login thread takes and if it takes more than for example 15s you notify users that their SavedVariables is close to being oversized?

It's not correct to say that "15s login time == user is about to hit the threshold & break things". The actual limit is 19 seconds, and we can slip by just fine most of the time even if the total time is greater than that; the user will just have to deal with a brief period of being able to play the game but WA isn't "active" yet.

Generally speaking, i don't think it's our place to nanny our users if they actually want to have a billion auras. I only opened this ticket because it's a specific pattern which we might be able to use to accurately find things that most users don't care about losing. Otherwise, if they come to us for advice about performance, we can suggest they pare things down, but i would prefer that users feel empowered to make their own choices* about what counts as "too many" auras.

* on the flip side, one could say this is just empowering users to ruin their own experience of the game. But in that case, where can you draw the line such that it won't chafe?

ok, so possible workaround; in information tab, if "old content" warning is set, add a checkbox to suppress. User can opt in to having huge SV without us complaining & effectively restore previous behavior? or is this just a complex way of doing nothing?

Information tab for groups doesn't show the warning section, i need more time to evaluate how complex it is to implement