Hi @CTMacUser,
For this reason, I don't think a lazy split should have a max splits capability. That mainly exists as a kind of halfway-to-laziness feature of the eager split so it's benefit is really marginal in a lazy version. Lazy bidirectionality is far more valuable.
Alternatively: instead of the default argument approach the eager version has, write two versions of split: one that has a max splits argument, and one that doesn't. Have them return different types. The type returned from the no-max-splits version can be bidirectional. This also means the simpler no-max-splitting version doesn't need to spend time at runtime checking if it needs to account for a max splits. However, this is a lot of complexity and not really worth it (opaque types would let you hide the complexity in the future, but could still lead to confusing type checker diagnostics). The nice thing about this approach is it can be added later in an ABI-stable way so there's no downside to leaving it off for now.
My suggestion would be for the lazy sequence split to pull off [Element] chunks.
So all you need to do is stash the base iterator in the lazy splitting iterator, then consume from it into an array that takes the place of the old "subsequence" that it then returns. The iterator will also have to stash one element if coalescing empty regions (because it needs to hunt forward for the first non-empty one, thus consuming the first element of it from the iterator).
This is admittedly no longer quite so lazy (you're producing arrays for the fields) but I don't think you can do it the other way without getting entangled with reference semantics for the iterator.