Current version works already quite well, developed against applying it to a few tier-1 and tier-2 KDE Frameworks modules.
A few corner casess still need care, but otherwise already pretty much a prototype which is not too far from a production version.

So feel invited to investigate by reading at least the API dox and check the examples given there.

Sure :) Will be done, once I know investment makes sense. For now interested in feedback whether the principle approach makes sense and is welcome/wanted, and what people think about the API of the macro as well as the generated API/macros for use in the code.

Great work. Not really easy to grasp at first sight (because it handles BC for no-compat builds of the lib itself, which we never did before) but this is certainly quite comprehensive.

Since we don't yet have any source compat to worry about for these macros (unlike Qt, which needed _X variants for that), how about simply adding a third argument to FOO_DEPRECATED_VERSION right away, to allow specifying a hint in the compiler warning, provided the compiler supports C++14?

Great work. Not really easy to grasp at first sight (because it handles BC for no-compat builds of the lib itself, which we never did before) but this is certainly quite comprehensive.

It's basically trying to solve 2 problems at the same time, as they both would be solved by the same macro techniques:
a) allow control over warnings and API visibility to people building against the library (incl. 2 level settings by additional library group level)
b) allow building of the library itself with legacy code stripped

If there are suggestions for better wording of variables/arguments, or improved ordering/threading of the documentation, all eager to hear. Myself still too much into thinking about details to be able to simulate a first-contact experience again, where ideas are taken from docs and term semantics :)

Since we don't yet have any source compat to worry about for these macros (unlike Qt, which needed _X variants for that), how about simply adding a third argument to FOO_DEPRECATED_VERSION right away, to allow specifying a hint in the compiler warning, provided the compiler supports C++14?

If your first version just ignores the argument, at least we'll start writing those hints and we can work on making cmake's GenerateExportHeaders support that, or fork it here to support it.

As there might not be always a simple hint text, I would still like to also keep the just-version variant of that macro. So if we overload the macro name to support both 2 (major, minor) and 3 (major, minor, message) arguments, any simple way to do default argument value with C++ preprocessor macros? Never wrote such code myself, all things I just found do complicated dances around __VA_ARGS__ of which I none could resolve to a simple application for our single-parameter default value yet.

So, any C++ macro magicians around to be able to tell how to support both

while also making sure there is only one argument, and not many? (at least that would be my ambition here to catch this ourselves, instead of just taking __VA_ARGS__ and pass it on, to fail later if >1 args are used.

bump since-version to 5.64.0, as currently targetted introduction version

Hope is review can be finished at 5.63 tagging time, so this macro would be
added right after that and all the ideally prepared patches for the KF
modules, so there is a full KF release cycle of testing in git master before
things get rolled out to users.

I wouldn't offer both variants, but rather recommend always adding a hint. At worse that hint can be "See method documentation" or an empty string. I think we're just over-complicating things otherwise, for no actual gain, since providing a hint is good practice anyway.

Quick update:
Currently still busy trying to get unit tests done, half-way through that. ETA begin of upcoming week.
Next plan: see how only having the 3-arg-FOO_DEPRECATED_VERSION(major. minor, message) would work by using that in the experimental patches done for some KF repos.