Update the Measure Properties dialog so the effect applies to all selected measures (or include a checkbox in the dialog for that option.)

A complication is developing a UI for cases where the initial values differ. For example, what would show as the "nominal" and "actual" duration when the selection involves multiple time signatures and/or multiple measures set to a different actual values? In the Inspector / Properties dialogs, we update immediately upon change of any single value, so we never have to deal with the question of how to handle a whole dialog full of values where some differ between selected elements but others don't.

Not saying it's not worth considerating a design for, but it's not as straightforward as it might appear at first glance.

MS Word deals with (some) situations where a selection includes text with different properties by setting those properties blank in the relevant control.

For example if you have have a section using Times Roman and an adjacent section using Arial, selecting both sections will show a blank field in the Font dropdown in the Ribbon. However, this doesn't work for on/off settings like bold or italic. Selecting a word in normal text and in bold shows sets the bold button in the Ribbon to off. That latter behaviour seems difficult to avoid as such a control can only be on or off not "undecided". In the MuseScore inspector that difficulty would apply for tick boxes and the "Reset to style default" buttons - and possibly others I haven't thought of. However, blanking "text box type" controls when they refer to multiple values would seem a reasonable way to go.

How to show the result is one issue; how to handle it is another. Basically, you need to implement a way of tracking whether the user has modified this value or not, and if not, then don't touch it when pressing OK or Apply, but if they have touched it, then you do need to apply that value to all elements. It's not an unsolvable problem, but it needs to be carefully considered, which is why no one has yet tackled this.

Looking again at the MS Word behaviour, suppose we have the following three text items:

Item 1 - Using all defaults - i.e. unmodified
Item 2 - Using non-default font 1
Item 3 - Using non-default font 2

If just one of these items is selected the font selection control will show the current font of that item. Changing the font in the control changes the font in that item.

If any two or three items are selected the font selection control will be blank. If a font is selected in that control it will be applied to all selected items.

I don't see that the user having changed something affects what the behaviour should be when a value is entered into the control - the new value should apply to whatever has been selected.

Hmm, yes, undoability? How should that work? In Word, the undo button reverts all the changed items to the pre-change state. That seems to be what I would expect. However, how would that be implemented I wonder? There could be quite a lot to keep track of. Does MuseScore maintain an undo stack for all operations?

Another thought to throw into the pot and getting to the specifics of measure properties: how would the "Add to bar number" setting be handled. If it is set to zero, bar numbers increase by 1 per bar. What happens if that is set to 1 do you get bar numbers increasing by 2 per bar?

The devil, as always, is in the detail!

"I don't see that the user having changed something affects what the behaviour should be when a value is entered into the control - the new value should apply to whatever has been selected" - well., yes, "a value is entered into the control" is exactly what I meant. We need to differentiate cases where a user changes the value from the blanked out default versus is they didn't. Again, not unsovlable and we've solved it elsewhere. It just requires work, which is why it hasn't happened. A dialog that affects only a single element is easy to design and implement and everything works perfectly right out of the box. A dialog that works in this way is a bunch of extra code to handle these cases. It can be done, someone just needs to volunteer to spend the extra time doing it.

I don't understand why the implementation was possible in the inspector and not here ?
What is the difference ? Why what is easier in the inspector ?

To be clear, it required extra work in the Inspector too. But, the work was simpler because Inspector fields apply immediately - there is no need create and manage a whole extra set of temporary values just to track which fields were modified and which were not. If field is modified, that action is applied immediately; no need to somehow store a separate set of flag to remember which fields were actually modified so you only apply those upon hitting OK. In fact, one fo the reasons the Inspector came to be was to solve the similar issues that existed with the text properties and other per-element modal dialogs back in the day.

Again, it's not unsolvable, and it isn't rocket science - it just requires some extra work above and beyond the standard way dialogs are normally processed, and requires thought and a UI design, it's isn't something that can be implemented just via algorithm changes.