Does this work? It's a signal. Won't this only warn at emit time? (while QT_MOC_COMPAT is what leads to a warning at connect time)

Asking because you didn't do this in D24465 for the windowChanged() signals, so something seems inconsistent.

(pre-existing) QT_MOC_COMPAT for a slot? Any idea what this might do?

No idea. I started a few times to look up what QT_MOC_COMPAT actually is about, but never had quick results, so delayed into the future.

Just had a look again, but as before stranding with MethodCompatibility from qmetaobject_p.h, which seems though nowhere really used.

So far my guess has been this is some relict from Qt3 times no-one ever properly cleaned up?

This being one of my experimental repos chance is I forgot to remove the KXMLGUI_DEPRECATED_VERSION here, and was blind when I checked the patch before uploading.
Let me check again if the deprecated attribute actually gets triggered on memberfunction-pointer based connect, not sure right now,

Taking this from the other side: warnings when connecting to deprecated signals actually work. They happen in check_and_warn_compat in qobject.cpp

... this does support warning about connecting to compat slots, so my comment was bogus, this is fine.

For the usual case, compat signals, the code checks signal.attributes() & QMetaMethod::Compatibility.

Ah and I found where MethodCompatibility (which has the value 0x10) is actually set...
the generated moc code says

6,    2,   89,    2, 0x06 /* Public */,
8,    2,   94,    2, 0x16 /* Public | MethodCompatibility */,

See the second line, it has the 0x10 value in there, which means MethodCompatibility is set.... by value, not by name.

I'm just still a bit confused about the relation between the 0x10 metaobject flag and the signal attribute which has value 0x1...

enum Attributes { Compatibility = 0x1, Cloned = 0x2, Scriptable = 0x4 };

But it must work, tst_qobject.cpp tests that QT_MOC_COMPAT ends up setting QMetaMethod::Compatibility in attributes().

Anyhow, I still believe that using the *_DEPRECATED macro on a signal only makes sense if we want to prevent subclasses from emitting the signal. Theoretical possibility, extremely unlikely for KActionCollection, but... why not. We can do this consistently everywhere without the need to consider the likeliness of subclasses, I suppose.

Okay, so "QT_MOC_COMPAT" is still a (just undocumented) thing, and thus something we should use for deprecated signal/slots then as before, right?

Had now another look based on your info, and found that the magic to map 0x10 onto 0x1 happens in the getter of the method attributes:

int QMetaMethod::attributes() const
{
    if (!mobj)
        return false;
    return ((mobj->d.data[handle + 4])>>4);
}

So that mystery seems solved :)

For adding deprecation attributes via _DEPRECATED to signals, yes, would agree to do this consistently then, following your argumentation. Will add this to the howtodeprecateallkindsofapi text I yet have to write, so far delayed to first gather experience.

Just remembered though: seems that Qt code itself no longer uses QT_MOC_COMPAT? At least I had no hits for actual usages in Qt classes when searching in my local Qt headers, via code.woboq.org or github search, there only for the old unsplit qt repo (which once made me think this is a Qt3 relict).

And given the #ifndef QT_NO_DEBUG does this warning land in normal Qt builds? (sorry, not build Qt in a decade).
till have to test with my openSUSE TW, will do later today.

Fixed to KXMLGUI_ENABLE_DEPRECATED_SINCE, as slotActionHighlighted is a virtual method, which the compiler needs to always know about.

Eh, fixed to KXMLGUI_BUILD_DEPRECATED_SINCE actually :)

I just realized this is false-y deprecated. The feature adds the configuration options for toolbar buttons.
What needs to be done here for proper deprecation is port that over to customContextMenuRequested or checking for policy being not NoContextMenu or so.

For reference:

Deprecation of custom context menu enabling methods in favor of QWidget::contextMenuPolicy was done 2007: R446:41c7dd48afbf2794dbe260466d569d808d851c04
And implementation code wrapped in 2010: R446:52905e8d94ee6d7a08ff1b793c5dd226f0c3fbc1

Guess best is to add a TODO into the code for now, unless you are already on it?