[For some reason, right now my Maple 9 does not start, and I don't have Maple 9.5 on this machine]

Compare the context menu obtained from the (output of) <<1,2>|<3,4>> in Maple 8 and Maple 10-11-12.  Very different.  Also note how much faster the Maple 8 version of the menu comes up compared to 10-11-12.  The original design of the context menus [I know, I did it] prized two things: 1) speed, 2) usefulness. 

But pretty much every single context menu (on integers, polynomials, etc) have changed between 8 and now.  Sometimes they are better now, sometimes they are much worse.  Pretty much always they are much slower to come up.

Apparently my notion of "recently" has been evolving over the years!  I guess I knew it was not so recent, and I knew that I disliked this change intensely, but never had anything but my own opinion to offer for my dislike.  So when I saw a UI expert clearly articulate a principle that was violated by the 'new' CM design, I finally thought that I had objective grounds on which to complain.

I did talk to the author of the new CM; the basic conclusion was that he was the programmer, not really the designer, and that various of these design decisions were given to him as constraints.

And of course it slowed down!  The design of the previous CM was extremely careful in this regard [even though a couple of bugs slipped in].  We knew, from the UI literature, that anything above 200 msec (ie .2 sec) was too slow for a menu.  In fact, around 100 msec is considered 'acceptable.  And this is a flat number, it does not depend on the 'size' of the underlying object.  In Maple, the only way to get things to be that fast is to do structural analyses of objects [via op] and eschew all commands that do expensive traversals.  Then only compromise was the use of 'indets', which is where all the bad slowndowns were [many of which were fixed by making indets smarter, which benefited the rest of Maple too, which in my mind is always the 'right' fix].  But any kind of analysis that requires multiple traversals, or worse, tree traversals instead of DAG traversals, were doomed to fail.  So the old CM code was designed around the best structural analyses we could do that would return 'useful' information.  So, 7 years ago, on machines many times slower than today's, CM came up essentially instantaneously.  Now, on fast machines, it is sluggish.  [All of this is about the library-side code].

Another part of the design was to have maximally useful items show up on CM.  We knew, from the same literature, that finding an item on a menu is linear in the distance from the root of the menu; basically, if a menu is too long, the things at the bottom will be more aggravating to use than the overall benefit of the CM.  So things were (subjectively!) ordered from "most often useful" to "of use, but less often" and everything that was only 'potentially' useful was kept off the menu.  It was not an issue of 'building the menu' speed, it was an issue of cognitive efficiency for humans that was the driving concern.

As far as CM items that are "wrong", that is a much more difficult problem.  Some of them are "very rarely useful", so are more clutter than anything else.  Some of them seem to be there purely for marketing reasons.  Others are downright frightening: giant words that are difficult to parse are used where simple words would have done better.  3D plot is much superior, from a recognition and cognitive load perspective, than 'visualization'.  While I am sure I could find 1 or 2 items which are "wrong", the real problem is much deeper.  If there is agreement that the current design suffers from deeper problems (ie too slow because it uses analysis methods that are too expansive, and disobeys very standard UI guidelines on cognitive load), then I can help with some concrete suggestions.