here's a simple (60 sloc), zero-dependency/zero-config, high-performance express-middleware for serving files, that can broadcast a single fs.readFile() operation to multiple server-requests. the entire standalone program (including emulated express-server and client-side stress-testing) is under 200 sloc, and written entirely with glue-code and recursive-callbacks (similar to how one would go about writing an awk program).
* this zero-dependency example will demo a simple (60 sloc), high-performance express-middleware
* that can broadcast a single fs.readFile() operation to multiple server-requests
That gives me the ability to name any task I want and resolve those asking for such tasks whenever these are available.
A further call to `broadcast.that('expensive-task', other)` would update the resolved value and notify those that setup `broadcast.all('expensive-task', callback)`, which you can also `.drop()` at any time.
Yet, having a way to hook into these kind of flows in core would be great.
user asks for a very expensive task clicking section A
while it's waiting for it, user changes idea clicking section B
both section A and section B needs that very expensive async call
drop "going to section A" info and put "go to section B" to that very same promise
whenever resolved, do that action
A caching mechanism to trigger only once such expensive operation would also work, yet it's not possible to drop "go into A" and put "go into B”
for your scenario, what you want is a cacheable background-task, where you can piggyback B onto the task initiated by A (e.g. common-but-expensive database-queries that might take 10-60 seconds to execute).
its generally more trouble than its worth to micromanage such tasks with removeListeners or make them cancellable (maybe later on C wants to piggyback, even tho A and B are no longer interested). its easier implementation-wise to have the background-task run its course and save it to cache, and just have A ignore the results. the logic is that because this common-but-expensive task was recently called, it will likely be called again in the near-future, so let it run its course and cache the result.
here's a real-world cacheable-task implementation for such a scenario, but it piggybacks the expensive gzipping of commonly-requested files, instead of database-queries  
Based on feedback, I agree that a blanket `Promise.prototype.clear()` is a bad idea. I don’t think that is worth pursuing.
I still think that there is value in this, especially the adding and removing of listeners you have reference to as Andrea’s PoC shows. Listeners would prevent the chaining issue or alternatively I think it would definitely be possible to decide on intuitive behaviour with the clear mechanic. The benefit of `clear(reference)` over listeners is that it adds less to the semantics.
I think the proposed userland solutions are bigger than I would want for something that I believe should be available by default, but I respect that a lot of the people in this conversation are in a better position to make a judgement about that than me.