FL, Versioning and the bane of compatability

[Salanto]

TLDR: FLs function needs to change and actively tell the client if the server considers it unsupported, even if it's too new. Compatability code should move to the server-side for authority and compatibility sake. This also means AO needs to follow something akin to semver, or a little dumb spin-off cause boy is our decision-making questionable at times.

THIS CAN BE CONSIDERED BREAKING SUPPORT OF LEGACY VERSIONS AS WE KNOW IT

FL :
Being born to disable client features to remain compatible with older servers, it has become a bloated mess that can turn a 2.10 client back to the olden days, where a modcall was considered a luxury, not an expected feature. Smart as it may be when conceived, it is now a trail of times gone by, but also shows that no feature after 2.1 is considered essential to AO2.

A potential redesign could be the server sending supported versions as opposed to supported features, enforcing a stricter design and versioning by conception.
Now, you may ask why we don't just kick clients we consider outdated. Well, this would also handle the case of a client being too new and failing parsing due to the extra/different data it sends.

Versioning :
AOs versioning is a mix of "yeah, let's bump the version later and FL the feature" and "yawn, bored now", Using stricter guidelines on when versioning happens and how to approach them would aid the client development as one can easier see the implications of an update. 2.10.1 could be anything from a full rework or minor bug fixes right now.

Compatability:
GET. IT. OUT. OF. CLIENT.
The client should not be responsible for maintaining compatibility with the many, many, many servers that are out there, cause for any server there are at least twice as many users using different versions.
What is easier in your eyes? Updating one server to support the new versions and broker older packets for the newer clients and vice versa? Or have EVERYONE update their clients or download bug fixes on their client in order to pair correctly with a legacy client. (Looking at you 2.8 offset)

In conclusion, taking no steps will only increase the problems of handling the legacy of AO2.
Change is scary, we have all been there, but keep going and nesting code into older code should not be a design to strive for.