Certainly, I'd argue that it's generally better practice to do the work
in popFront, because front does frequently gets called multiple times, and you
almost always end up calling front if you call popFront.

Actually, the way phobos is designed, often times it's easier to specify what front does, eg with map and related functions.

It's possible that map, joiner, and or array could use some efficiency
improvements, but I wouldn't consider the difference in the number of calls to
front to be a bug. At most, it might indicate that there are some optimization
opportunities in one or more of those functions, and it might even be that the
differing number of calls makes sense when you actually dig into the source
code. I'd have to go digging to know for sure.

it's not just an issue of optimization opportunities, it's an issue of correctness and principle of least surprise; the code I shown was simplied from a larger bug I had where I was doing side effects in the map lambda that were meant to be called once per element instead of multiple times.

Is there a convenient to achieve the same effect as this:

elements.map ! fun_with_side_effects . joiner . do_something_with_result

but such that fun_with_side_effects is called only once per element ? (likewise with other functions that operate on ranges).

As it is, joiner and friends is dangerous to use with generic code because of that. std.array.{array,join} doesn't have this issue.

why not modify joiner (+friends) so that:

if front() is pure, allow calling it multiple times

if not, make sure to call it only once per element