Actually, I'm thinking that the fix may be easier than I thought after all - if I add a 2-arg "range-checked" constructor as an overload, then the iterator's constructor can validate the end-points of the underlying sequence during construction, and there's no need to otherwise change the implementation or add overhead by checking every increment/decrement for movement out-of-range because we'll know that it can't happen.
...unless the characters are modified in between traversal operations. I don't know if that's a legitimate concern or not, just thought I'd bring it up :/ *If* it's remotely a concern, probably sufficient to just document this limitation...?
IMO changing the underlying sequence while you're iterating over it with an adapter is a recipe for disaster anyway, so no I don't think it's an issue in practice. John.