Some bugs of and update suggestions for MuseScore 3.0

Thank you for your reply!

0a. I have posted this message for 3 times because each time I send it I received an "accessed denied" error when trying to access the newly created thread: I have interpreted it as a site bug and thought that my message was lost (because I didn't get minimal feedback from the site at that time). I have tried to access these two threads each day after the posting day-1 and received the same "access denied error".
https://musescore.org/en/node/281142
https://musescore.org/en/node/281144
In the end, I have interpreted this a serious bug of the site and have sent my message directly to the technical team with the "contact us" form.
0b. You didn't see my message from the first day probably because of the site bug.

1a. There is a "universal" musical pedagogical standard (in the sense of "Western", because the standard 5-lines staff is of Western origin with no claims to be "universal") in which notes are taught and learned from down to up, from middle C to the next notes of the scale (because the treble staff is generally the first to be taught and learned). I am glad that some forum users reported this down-to-up standard, each from his country, from Wikipedia or from various dictionaries. The Romanian school of music also uses this standard bottom-to-up numbering. The universal pedagogical principle of numbering is simple: lines are numbered bottom-to-up as notes are also numbered in the same order (from bottom-to-up): C is the 1st note of the C scale, D is the 2nd note of the same scale and so on. It is unnatural in pedagogy to number the lines in the inverse order than the notes starting from C to up.

1b. I am sure that MuseScore builders inverted the line numbering (from top to bottom) as strongly influenced by the fact that the pixels on a screen/window (controlled by software) have (x,y) coordinates that increase from top to bottom (and not inversely, as it is currently used in Western music, when numbering lines from bottom to up). I am a programmer too: however, I didn't fall into this "trap" when programming my LeadMuse (which uses a periodic modular bilinear staff):
https://www.researchgate.net/publication/325877146
https://www.academia.edu/36909545

1c. It may be "non-standard" in Western concert music to use staves with less than five lines: however, in Western musical pedagogy, many teachers prefer to initally use only the first 2-3 lines of the staff (numbered from down to up!) to initially teach the 7 notes of the C scale in ascending order. What is "non-standard" in concert music isn't necessarily "non-standard" in pedagogy, on contrary. MuseScore should give the same attention to both types of music approaches: from the teachers' view and from the interpret's view.
The Wikipedia page dedicated to the musical staff has a phrase which expresses the almost "universal" (in the sense of "universal in the Western music") line numbering used in the Western standard musical notation system:
"The lines and spaces are numbered from bottom to top; the bottom line is the first line and the top line is the fifth line."
https://en.wikipedia.org/wiki/Staff_(music)
The first 2 lines of the musical staff (the E-line and the G-line) is also the foundation of many non-standard (including bilinear) musical notation systems which all use the bottom-to-up numbering:
http://musicnotation.org/systems/gallery/
(note that in MANY 2/3-lines non-standard notation systems [presented in the previously linked webpage] the C note has a ledger line and is placed UNDER the 1st line of the staff, which is clearly the E-line and not the D-line as MuseScore 3.0 imposes).

1d. The fact MuseScore imposes the 4th (D-line) and 5th line (F-line) (instead of the 1st E-line and 2nd G-line or any other pair of lines) is a subtle bug, which may be called a "non-wanted ambiguous option/choice": the arbitrary pair of lines imposed by MuseScore is often contrary to what a music teacher wants and that is frustrating for him/her. The elegant approach of this subtle bug (of arbitrary and ambiguity) imposed by MuseScore 3.0 can easily be solved by a small form with 5 checkboxes near a small 5-lines staff (one checkbox for each staff line, numbered from down to up) so that the user/teacher may choose which lines to use in his pedagogical method.

1e. In a checkpoint conclusion, I hope to have demonstrated you that your "extreme" phrase "there is nothing universally standard about how staff lines are numbered in music" should be replaced with "the bottom-to-up numbering of the staff lines is an ALMOST <> standard in Western music", because MuseScore 3,0 doesn't pretend universal musical features in the strict sense, BUT MuseScore is essentially and mainly based on the Western musical notation system (not a universally accepted one on "the whole Earth", which doesn't exist yet): additionally, the great majority of the non-standard musical notation systems use this bottom-to-up line numbering system (as already explained)

1f. The combination of using Staff type change and the inspector tool (which generates a bug and is an artificial one) is much more inelegant that the solution I have proposed: numbered checkboxes from which the user to choose what lines of the staff he really wants to be shown in the score.

2. In music, composers (I've been composing music for more than 20 years) often use groups of two or more chords to copy and paste (and then modify some chords) from one passage to another: it is a nightmare for me to copy or re-input each chord in a passage instead of pasting the group of chords automatically on that passage, even if that passage contains tuplets. The chord group paste in any group of bars should be equally simple no matter if that group of bars contains tuplets or not.

3. I am glad that many reported bugs are on the list of feature MuseScore updates/repairs.

4. I will also report this issue (as adviced by you) from the "Help/Report a bug page".

Regarding the other suggestions:

1) I was referring to the palettes from the left side of the screen (when looked at the screen): when I choose a clef in a bar (from the sheet) for example, the palette (from the left pane) showing all possible clefs offered by MuseScore should open automatically (so that all clefs [that may replace the selected one from the score] should be visible) and all the other palettes (from the same left pane) should close automatically. It is very annoying that each time anyone wants to change an element in the score, he/she needs to select the element to be changed (a clef for example) and then go with the mouse in the left palettes pane, find the corresponding palette with all the similar/alternative musical symbols for the one chosen in the staff, open it and then double click it to change the one selected from the staff. I hope that now I've made myself much more clear in what I wanted to report.

2) I will search the Handbook under "Custom palettes".

3) I meant controlling the space between staves directly from the score, with a drag-and-drop mechanism (select a bar from a staff and drag it up or down and obtain a local respacing between two adjacent staves): it is very time-wasting that for each spacing detail from a score to move the mouse in the extreme left of the screen and choose a spacer from the spacers-palette (instead of directly maneuver the staves with the mouse, by drag-and-drop, like in Sibelius for example).