Re: Overlap between StreamReader and FileReader

We're investigating about ProgressPromise and EventStream discussions.

In thread "[promise] writing detailed spec of ProgressPromise &
implementing it" of www-dom, Domenic said

As such, I would suggest representing it as such a side-channel. In
> particular, for your directory-picker UI, I'd suggest an object such as `{
> openSystemDirectoryPicker, addEventListener }`, or if you think that's not
> ergonomic, then have `openSystemDirectoryPicker` return an object that
> implements both `Promise` and `EventTarget` interfaces. A special
> progress-promise, that departs from standard `EventTarget` mechanisms and
> presumably entangles itself into the resolver etc., causes the problems
> outlined above.


I think using a new interface implementing Promise & EventTarget as results
of Stream::readXXX methods is a reasonable choice.
So I have a question. Why current Stream API discussion introduces
(Abortable)ProgressPromise instead of making a new interface implements
Promise & EventTarget?
I'd appreciate it if you would inform me about this.