At least for me it's more complicated than implementing them.

But if it's easier for you to baptize reduce-like maps, greps, parts, and so on in a quick post, I would appreciate to hear your suggestions

If I was forced to chose only one implementation I would certainly chose a reduce like map, like you did, because it has the biggest flexibility.

But I'd prefer to have a solution where map is still named map and grep ist still grep!

IMHO extra options and special vars should activate and supply the needed functionality.

As already stated in the OP the need to appropiately name a whole new family of reduce-like iterators is an extra problem.

Your always free to not give it a name, leaving it as

my @b;
for (@a) {
   push @b, $_ if !@b || $_ ne $b[-1];
}
[download]

or

my @b = list_reduce { 0, $a || $b ne $_->[-1] ? $b : () } 1, @a;
[download]

But they're not very readable.

But I'd prefer to have a solution where map is still named map and grep ist still grep

You complain that there's "a lack of iterators allowing to compare successive elements", yet you wouldn't want to use them if they existed?