Hi, what about "Apply", I think that more frequent and important. must click twice in new drag menu. thanks

Yes. There should be more shortcuts.

Currently, if a user wants to apply all modifiers of stack at once ; he has to go into Object menu > Convert to sub-menu > Mesh from Curve/Meta/Surf/Text.
That is funny but that should not be the case at all.

A clean UI should exposed same things as things exposed by Modifiers Tools addon.
That is a community addon.
https://docs.blender.org/manual/en/2.83/addons/interface/modifier_tools.html

But it really only provides basic things to manage modifier stack that should be there by default.
An Apply All button, a Delete All button, a Viewport Vis button to disable/enable all modifiers in viewport and a Toggle Stack button to close it entirely or open it entirely.

You may not be a big fan of buttons. Those features could be added to menu and have shortcuts.
But there should be present by default and discoverable without the need to enable an addon.

Generally, +1! As discussed before, I agree it would be nice to have more utility operators like "Apply All", "Move to First", "Move Up", etc. They can go into the new menu with the down arrow (EDIT: oh, there's D8040 already :) ), although we should probably also consider adding these things to the context menu.

For the implementation, for newer code we usually let operators act on the UI context. So they check which button is "active", i.e. under the cursor. See usages of UI_context_active_but_get() or UI_context_active_but_prop_get() for example. We could do the same for panels: OBJECT_OT_modifier_remove would use the UI context if no modifier name or CTX pointer was set, checking if the hovered panel is a modifier panel.

The benefit of this is that the shortcut becomes configurable. Users can also disable it if it gets in the way for whatever reason. And I think you don't need the UI_ITEM_O_HAS_SHORTCUT flag then (or maybe you do...), it should detect that automatically.

I'm not against this current solution though, it seems quite fine too.

The only issue really is that it can be easy to accidentally duplicate modifiers if you try to add drivers with the D key. Luckily using D over widgets swallows the input so it doesn't both add a driver *and* duplicate, but if you miss the widget, it will then duplicate. Similar issue for the shortcut to reset values. IMO, the X key is too easy to accidentally hit without any warning, which is why it pops up a confirmation popup in the viewport. For the Delete key we don't do that, because it's sufficiently out of the way to accidentally hit.

A solution to this could be to use the Delete key for deleting immediately only, and adding a popup for the X key, and using Shift-D to duplicate, both of which are sufficiently different from those other widget keys.

In D8031#195030, @Julian Eisel (Severin) wrote:

... OBJECT_OT_modifier_remove would use the UI context if no modifier name or CTX pointer was set, checking if the hovered panel is a modifier panel.

I'm not sure that fits so well here. That seems like tying this specific implementation of the UI a bit too strongly with a general operator. I saw most uses of the functions you mentioned in interface code.
For one, the code to check if the mouse is in a panel exists, but it's local to the panel code. And the check for a "modifier panel" would have to be the panel context string and the INSTANCED flag. It just seems a bit hacky.

Also, if we added a shortcut to the whole operator and it displayed automatically, it would display everywhere it was added, not just here in the properties region, right?

If you felt strongly I'm happy to pursue it, but I'm personally not convinced it's a large enough improvement.

In addition to what I just said, it looks like panels don't store any data about whether they are below the mouse like buttons.

In D8031#198243, @Julian Eisel (Severin) wrote:

This crashes for me when trying to load factory settings.

I can't seem to trigger this! Could you provide more detail?