No Kovid, I don't think I can do that, for two reasons. The biggest is because so many of the plugins have their menus completely rebuilt on their own bequest, it is not practical for my plugin to try to hold any links to their QActions for a period of time longer than at the time the user clicks on the button to show my menu. A large number of my plugins in particular have very dynamic menus, where the menu must constantly rebuild itself when the user creates new lists, configures new menu items etc. Even if that wasn't the case, how could my plugin work out the very first relationship with a menu at calibre startup, other than trying to walk comparing the menu text?
The second reason is that the user can rename menu items on my menu. Say for instance a user chose to put both Edit list -> List A and View list -> List A on their Favourites menu. The default names for those are going to appear as "List A" and "List A". So to stop their confusion they will rename them to "Edit List A" and "View List A". That of course means that the original name which is constantly changing due to the counts being appended to it cannot directly replace their custom name.
Now I could deepen the filth of my hack and have my plugin append the (#) count to whatever display name the user has chosen if push comes to shove but it is grubby enough putting in a special case for a plugin named "Reading List" as it is
The other idea I had was to use a hasattr() check against the QAction and look for a specially named attribute, like "favourite_menu_name" or whatever that represented the non-dynamic version of the name. However that would mean me having to make a change to the Reading List plugin to implement it, and also rely on every other developer in future who writes a plugin with a dynamic menu name to also implement it. It may come to that one day, but for now I kept the filth constrained to within this plugin