Brackets do not display on single instrument if others in group are hidden

If I understand correctly, the issue is a bracket does not appear on a staff if the other staves it is connected do are hidden?

Seems reasonable, although there are cases where this would not be desired, so it would be important to be able to maintain the current behavior as well.

Yes, I have this problem too.

But, as Marc says, having an option would be good, as I think I've seen both behaviours.

As mentioned, there are situations where it makes sense, and others where it doesn't. In the ones where it doesn't, being forced to see an unwanted bracket is equally "horrible". We should provide an option to control this. Maybe a property on the bracket itself, or perhaps a staff property, not sure which makes more sense. Would be good to have some forum discussion and come to a consensus on it.

For the record: MuseScore 1 did it that way. And without an option, always.

Bring up example scores from well-know and well-respected publishers that do have such braces in cases of a single line in a system.

Which scores, from which publisher(s)?
It is Choir only or also Brass, strings or woodwinds etc.?
What genre of centrury?

Name a few, proof needed...
If it is Choir only, MuseScore can't do this in the general case without options or with just a score wide option, but needs to be on a case by case (staff or bracket) basis, as there are other cases where it is not desired.
And yes, Choir staves are often different, like having dynamics above rather than below for example.

And no, it is not all of them, I don't have many, but at least one of those doesn't have brackets in the places where there is just one choir staff. In 2 other though it indeed is

I think MuseScore 1 only retains the group bracket if the top entry is present in the system; MuseScore 2 retains them as long as there are more than two entries.

I've attached an example of each.

The thing is, even if it were literally all choral scores, the world is bigger than that. There are many other cases to consider. For example, what of orchestral parts? A first violin part that splits into two staves for just one system for a divisi - should the rest of the part be forced to show a bracket? How about a marimba part that switches between one and two staves often? The piano part in a big band that is mostly two staves but reduces down to one for a few systems to save space? A lead sheet that is mostly one staff but uses a second staff for a bass line on a few systems?

These are all different cases that each have their own different requirements. And the current behavior is correct for some of those cases. That is why, as I have said, there should be a way to control this behavior.

And it isn't even all choral scores, for me it is 2:1.

Indeed, I just did a quick check on IMSLP, looking at choral scores in alphabetical order, and the very first three condensed scores I encountered that use brackets at all do it the way we do, with brackets shown only if there are multiple staves:

http://ks.imslp.info/files/imglnks/usimg/2/2b/IMSLP248145-SIBLEY1802.23…
http://petruccilibrary.ca/files/imglnks/caimg/2/2a/IMSLP347030-PMLP5605…
http://ks.imslp.info/files/imglnks/usimg/3/3f/IMSLP29368-PMLP65720-Park…

I wouldn't take that small sample size as evidence that not showing the brackets is standard, but it's certainly very good evidence that it's far from rare.

Absolutely agreed, as I have said from the beginning, we should consider adding an option in the future. But as I also said, we should discuss this on the forum where other users can give their ideas on how this option should be presented. I could see it being something in the Inspector the bracket itself, or I could see it being in Staff Properties, probably other possibilities as well.

Or in the Bracket Inspector "Show even if other spanned staves are hidden" or some such.

Question indeed is whether this is (or should be) a bracket property or a staff property, in the latter case we'd need to deal with conflicting settings between the connected staves, like when one staff's property wants the bracket shown and the other does not. Again that might not be a bad thing either, as it's allows for the bracket to show when e.g. the top staff is hidden, but to not show when the bottom staff is hidden.

Next thing to consider is how to implement it in a way that doesn't requite a score format change casuing score to not be readyble with older versions anymore, else it'd have to wait until MuseScore 4.

Point is: there's more to it to consider, it is not as simple as it looks at first

If it requires a localised setting, then probably 'Staff Properties'; if global, Style.

"Next thing to consider is how to implement it in a way that doesn't requite a score format change casuing score to not be readyble with older versions anymore, else it'd have to wait until MuseScore 4."

I think we discussed back-compatibility previously, but this was one of the reasons I was against it (means waiting for the next major version or potentially upsetting the representation of the score).

We've established the precedent that it's OK to add features like this at "minor" releases, so in principle it could come in 3.3, or 3.4, etc. A score using the feature would presumably still load in older versions (well, post-3.0), just might not look the same. Thus it would be just like any number of other changes we've made between 3.0 and 3.1, or 3.1 and 3.2.

FYI, there may not ever be a MuseScore 4, or if it happens it might be a long ways off. That is, there are no current plans to make any changes so drastic that they would require a major version bump (unlike the cast with MuseScore 2, where within a few weeks it was obvious that the things being worked on would have to wait for another major version).

It does require localised settings, as it maybe needed for a choir, but not for e.g. woodwinds or vice versa, within the same score. So either staff propertiy or a bracket property. I too lean towards staff property.
And yes, if we can get it implemented in a way that doesn't break score reading of older 3.x releases, we don't need to wait for MuseScore 4.

I think, in order to accommodate features such as localised Page Settings (or whatever else to attain the best typesetting), 4 probably will happen, but my guess is, it'll be one or two years before development starts. I know that's for another topic. :)

Unknown properties are normally ignored after printing an error to the console, so older versions would act as if the setting were simply still at the default. Thus, it shouldn't be a problem - you'd just get different results for any score that set this property to something other than the default. This ignoring of unknown properties was something we put in place starting around 2.1 (?), there might be certain exceptions, but staff properties look safe, and so do bracket.

To me somehow the bracket seems a more intuitive place to set this, then you need to set it only once for all the bracketed staves. But again, it really should be discussed on the forum to get more input.

There's no special reason localized page settings (I assume you mean different space or margin settings per page) would require a major version bump. Again, you just live with the fact that older versions will not recognize the feature and thus will display the score differently.

Marking this as a duplicate of #296075: Allow user to choose whether or not hide brackets which span to a single staff when empty staves are hidden as that one records, and will have been recording the whole process of analyzing and resolving the issue.