So, in order to produce a concrete result, at least the
point 2) should be accepted / understood. This is what I tried
to do, but the thread seems to go in the opposite way. This is
why I think that opening a ticket would be unuseful for now
and I did not open it. But if you think it could be useful, be
free (of course) to open it ...
This is precisely the heart of the question. LilyPond
development is
(mostly) not driven by the importance of issues but rather by
pleasure and
interest. Which means that you just need one person willing to
spend time on
piano pedals − and skilled enough for that − regardless of the
issue's
weight. That can happen now, or in months or in years, who knows.
In the
most extreme cases, issues can be resolved a decade after they
were
reported. Look at the one David Stephen Grant fixed just two
weeks ago:
https://gitlab.com/lilypond/lilypond/-/issues/1722
https://gitlab.com/lilypond/lilypond/-/merge_requests/119
This is why issues are so essential. They help organize work on
a long time frame.
By the way, the Type::Enhancement label expresses no
judgement about wether the
issue is a major one. It's to be understood as opposed to
Type::Defect: this ticket
is about an enhancement because the current output is consistent
and there is
no crash.
I opened https://gitlab.com/lilypond/lilypond/-/issues/6005
.
I would not proceed in this way.
The lack of a cautionary pedal on a bracket could be seen as an enhancement only in a self-referential context, which doesn't make sense to me. A proper way to proceed is to check what modern professional engravers do with it, and check as a consequence if Lilypond is coherent with them (-> common practice)
AFAIK nobody uses a bracket without a starting word in professional engraving, it would have too many bad side effects. And opening an issue as an enhancement IMHO will weaken the urgency of fixing this.
Best,
P