Staff type change: number of lines capped at eight?

I was surprised to discover the "staff type change" feature. There is already some discussion in the forum about how this feature is and should be implemented. When I saw this mechanism, I realized it could be a convenient way to create more readable sections in extended-range guitar music.

Guitar is normally notated on a single staff, despite the need for many ledger lines. This situation is exacerbated with extended range instruments. Because these outlier notes aren't used too often, we don't generally resort to using two staves. But I frequently create scores in which a short section must use up to five bass ledger lines. These are hard to read.

This situation is sometimes addressed in published scores by adding a bass clef staff to the measures in question, similar to an ossia. However, doing so in the usual way will add significant vertical space to the page. I realized that using a one- or two-measure section including the additional five lines, flanked by normal 5-line measures, would be intuitive to read if somewhat unusual.

However, although the staff/part properties allows a whole score to be created with many lines on a staff, the staff type change only allows three additional lines.

My preference would be to render such measures with eleven lines (i.e. spanning middle C plus the full bass clef). It would be even better if I could leave a gap for middle C followed by five additional lines, i.e. create a brief two-staff engraving section within a single-staff score, rather than using a quasi-ossia via image.

This rough example below shows 1) current ledger line confusion, 2) an interpolated bass clef section as might be found in published scores (and which might be possible via an expanded staff type change tool), and 3) an interpolated ten-line section (which would be possible if staff type change allowed more than eight lines).

Neither of these capabilities (more lines, or more lines with an optional "middle C gap") is likely to be used heavily, but it would allow for some clarification in these special situations, and perhaps if some refactoring is being done in this area they might be considered for inclusion.