First-order or second-order, does not matter. It is still a violation of the terms I agreed to in the Developer Agreement. I cannot say why it passed EW review, but it should not have. Giving one developer a “pass” and not others is bad policy. (It sounds like one of the toolbar editor extensions.)
It isn’t a toolbar editor. I’ll message you if you want to know (let me know). It did make me ask if the monkey-patch was a matter categorical rejection or a risk assessment. Meaning someone determined that what is does is not ‘technically correct’ but was ‘low enough’ risk that it was okay.
Yes I know which one it is, and the author has basically abandoned most all his extensions. He hasn’t been in the forum in over a year, and has not touched that old extension in six years.
It is basically obsolete since SketchUp 2022 when the native search feature was implemented.
I don’t think it should have been implemented the way it was. Using prepend or include and then calling super within the override should have been the way to go.
The “highjacking” of API methods was mostly because of the lack of several getter methods (at that time) that have since been added to the API (in 2022.) It is so very convoluted it would be a nightmare for anyone else to try to update it.
This is what gave me the idea to search.
It seems like the rough boundary of what is doable is to use UI::Command#proc, UI::Command#extension, UI::Command#get_validation_proc to harvest as much as possible of what is available.
Gather Sketchup.extensions, UI::Toolbar#each, Sketchup.get_shortcuts, and Sketchup.send_action. Use known send_action recipes and send emails to all past, present, and future extension developers requesting opt-in registrations.
Even without the last one a reorderable but incomplete menu launcher can be done: