Note that this applies to the type that you gave, too! There is no way to deduce from the type that the initial state won't be used to produce a value :)
If you do want that guarantee, then perhaps you could restructure the type as:
delimit :: (x -> a -> (x, NonEmpty b)) -> x -> Stream (Of a) m r -> Stream (Stream (Of b) m) m r
This type has some nice properties, too. For example, the first part is equivalent to a mealy machine:
{-# LANGUAGE ExistentialQuantification #-}
data Mealy a b = forall s . Mealy
{ begin :: s
, step :: a -> s -> (b, s)
-- ^ @a -> State s b@
}
... which implements all sorts of type classes (like `Category`, `Applicative` and `Arrow`) and supports nice lens-based combinators analogous to the ones for `Fold`
Using that type, you would have:
delimit :: Mealy a (NonEmpty b) -> Stream (Or a) m r -> Stream (Stream (Of b) m) m r
... and you can also generalize `Mealy` to a monadic version, too for `delimitM`
However, looking at this more closely I'm not sure that your original type for `delimit` is sufficiently general to handle most use cases for grouping a stream. If I'm reading the type correctly I think this assumes that you have one group of `b`s per original `a` in the input stream, which might not be the case. For example, consider this function that groups a stream of text chunks into lines:
lines :: Monad m => Stream (Of Text) m r -> Stream (Stream (Of Text)) m r
I don't see how you could implement that in terms of `delimit`
I think if you really want a sufficiently interface you should expose a `next`-like function (similar to `list-transformer` and `pipes`)
data Step f m r = Cons (f (Stream f m r)) | Nil r
next :: Stream f m r -> m (Step f m r)
You might still provide higher-efficiency combinators for grouping, but I think you will need the less efficient `next` primitive exposed as a fallback for the general case of grouping things