There's a possible argument here that we shouldn't have this branch at all. Even in non-clustered mode, we can (in theory) use a real future to make a call to ourselves -- and (in theory) this may be faster than executing the call inline (this branch is effectively executing all calls in a single-threaded serial way in-process).

I think it works this way because:

• when this stuff was first written, it was helpful to isolate the newer clustering code from the existing tried-and-true method;
• we can't really guarantee non-clustered setups can actually make HTTP calls to themselves, and we don't need this capability, and it's kind of a mess to debug if it's broken somewhere, I guess?; and
• in practice, "real conduit" has a lot of overhead today and is probably not faster for installs small enough to not need clustering.

None of these are amazing arguments for keeping this (and I think "fewer execution paths is better than more execution paths" is a pretty good argument for getting rid of it) but there's enough general messiness here that I feel like this less-ambitious approach to just fixing the future semantics is well within the realm of reasonable changes.