The documentation is indeed misleading:

• the analogy with ignoreAllTreesContent is currently incorrect, since the latter is consuming at most one tag;
• the provided examples are however correct as they clearly show that multiple tags are consumed.

I'm completely in favor of this change, but as is it looks incorrect to me: the recursive calls to takeAllTreesContent that you didn't remove, must be called many times, otherwise you will only match a single subtag at each layer of the tree.

Yes, see my comments on the issue. This requires some form of many to deal with multiple tags inside a tag. I was going to update this, but figured it'd be nicer to do it using skipMany (or whatever we end up calling it) from the other PR

One of these days I will learn to not push until I'm done testing...

ok, this is roughly how takeAllTreesContent should work, unfortunately this doesn't typecheck because many_ inherits it's Consumer using type signature from manyIgnoreYield, for it to work these would have to be changed/generalised to allow emitting results (something I'm not sure is desirable? It might be for many_, but probably not for manyIgnoreYield).

I don't know if there's a way to work around this restriction (I'm not too familiar with Conduit). Alternatively, maybe we should implement the more general version and export manyIgnoreYield with the current restricted type and change many_ to be more permissive and work with this code.

I'll leave you (@k0ral) to think on that, 'cause it's now bedtime for me.

Considering that all exported parsers are ConduitMs rather than Consumers, even though they don't yield anything, I'm assuming there was no intention to prevent users from yielding values within parsers (there's even a unit test that does exactly that), therefore it makes sense to have combinators work on ConduitM as well.
I've merged and fixed your changes, thank you !