[r-t] Opinions sought

[matthew at frye.org.uk]

Quoting Tim Barnes <tjbarnes23 at gmail.com>:
> Fully replicating current practice of what constitutes a spliced
> composition (at lower stages) is complex to write down -- it involves
> testing for changes of method at rows that are not points of completeness
> (in the sense of complete extents), but with some sort of exception to
> handle the one incomplete touch that a lower stage performance can have.
> This seemed to fail the "simple" part of the framework team's mandate.

Is this really that complicated? What I'm thinking is along the lines of:
"Any multi-method performance is spliced unless it can be divided into  
a series of contiguous round blocks, each of which is of a single  
method and contains each row n times, or at most one of which contains  
each row n or n+1 times."

Wording isn't optimal, but that doesn't seem too bad to me. Is there  
an example where that definition gives a counter-intuitive and/or  
wrong classification? I think that defining an explicit exception  
avoids both a lot of complication and the possibility of unexpected  
edge cases.

MF