OK, thanks for explaining. My intuition is that the type of promise created inside map/flatMap/filter/etc is not something that you'd want to change when extending Future. The reason for my belief is that I view the type of promise created and returned by these methods as being solely driven by the needs of the logic inside the methods, rather than being driven by the type of future that the methods are called on.

The logic for each of these methods goes like this: return a promise, use onComplete to wait for the value of the underlying future, do some stuff with that value, then complete the promise. This logic remains unchanged even if the type of future changes. If the underlying future type changes then it will change the implementation of onComplete, but all the logic in the methods remains stay the same. Since the logic stays the same, the default type of promise we return will still work too. I don't think we need to provide a hook that lets people change the type of promise used by that logic. (And we don't currently provide a hook either.)

Now some types of future might conceivably have their own way to map/flatMap/etc. But if that's the case then they can go the whole way and override the methods entirely. That of course gives them the freedom to use whatever type of promise they wish. :)

They only thing we're not giving users is a way to do their own linking of Scala promises. We're keeping the promise linking API private. I'm happy to keep it private for the moment. We can always expose promise linking in the API in the future if we see that there is a need. I'd rather be conservative about adding to the API. It is much easier for us to add to the API in the future than it is for us to remove something once it has been added.