layoutChanges in system objects

[rpatters1]

The reference manual states that layoutChanges are envisioned in particular for stem changes. If I understand it correctly (and I might not), it seems like they might also be needed for:

• mid-system instrument doubling changes
• mid-system changes in the number of staff lines
• mid-system cutaways. (That is, a staff is cutaway or added in the middle of a system)

The problem with tying these changes to a layout is that it requires replicating a huge number of elements. Imagine an orchestral score with cutaways. Every system could potentially have multiple copies of a long list of staves, most of which are not different. Maybe this is my Finale-centric brain, but it seems to me it would be better to have a single layout per system with some way to override staff attributes in the middle, rather than creating an entire new system layout. The number of permutations in a complex score with lots of staves seems like it could balloon the list of layouts to an absurd quantity.

To give an example: I not infrequently change a 1-line percussion staff to 5 lines for a bar or two (or less) to show a cue. If I understand layoutChanges correctly, this could result in 3 layouts for that system, and that's only for one staff. What if different staves have different changes at different times in the system. It becomes unwieldy both in terms of data and in terms of writing code to export or import them.