So how do you chain your implementations of hgrep and hmap? hgrep {...} hmap {...} %h ???

You don't. It doesn't make sense to chain the output of a function producing a list to the input of a function taking a hash.

If you need to post-process the output from hmap with grep, use grep.

There is no way to have hmap return a hash, or a hash reference, because the user decides what is returned from the callback. And what tehy return may make no sense as a hash at all.

If you need to post process the output from hgrep with map; use map.

Whilst it would be possible to construct a new hash from those pairs for which the user callback returns true; if you do so, and the user wants to post process the output as a list with map; or print it as a list; or assign it to an array or hash; then they then have to deconstruct the hash(ref) to do so.

Ie. the h stands for head (of the chain) as well as hash.

I'm saying it's safer to respect symmetry because nobody can anticipate all use cases, not even you.

And symmetry for its own sake is just pretty, pretty. Orthogonality where it makes sense ... makes sense; but otherwise it does not. And so far; neither you nor I have come up with a use case. But we are both aware of the many use cases for the output being a list.

In an ideal world, it would be a list of pairs. But you cannot initialise another hash from a list of pairs; and nothing else in Perl knows what to do with them either. I guess that hgrep hmap could output a list of pairs, and accept a list of pairs; and then have another function that flattens them (for assignment to a new hash. But it adds a 'final' function to the chain which is a cost; and as yet I see no benefit accruing from it.

That not to say that there isn't some potential use for using context (eg. wantarray) to decide whether to produce a normal list or (say) a hashref. Given a use case.

But I can see no point in building a hash(ref) for output if the next function in the chain is going to immediately deconstruct it to a list or list of pairs.