This is a relevant point, but I think Werner is right. You can put your dynamics in a Dynamics context. Currently, they would be removed completely, while with this patch, they would be kept entirely. Whatever the value of keepAliveInterfaces, this is no good solution for the kind of partitura that you describe (althought I tend to think that the latter would be less cryptic to the user). But with this change, the default behavior will be correct with a usual Dynamics, that is, if you just write spacer rests when you want no dynamics.
What we're debating here is the case where you put the dynamics together with the music in the same Staff context. Without this change, staves with rests only are removed whatever their dynamics. You could think this is useful, but what if the winds start tacet in the middle of a system? You will then have rests with dynamics on them. With this patch, all the staves will be kept as soon as they contain dynamics, and you will also have rests with dynamics on them. I don't think there is much better to do. Whatever the state of keepAliveInterfaces, there is no 'easy' solution: it's up to the user to split their dynamics variable, or use \quoteDuring, or write a very tricky function. As a result, I can see no situation where the current value of keepAliveInterfaces does a better job than the one with dynamic-interface. If someone does and can provide a concrete example, I'll gladly create a different value for Dynamics contexts, but if there is no real reason to do this, let's keep it simple. https://codereview.appspot.com/553760043/