Scala also takes the same way C++11 does, and to my mind it makes more sense this way. So from my perspective Javascript is the backward duck here. I agree it would be nice if we could all just settle on something
I agree the Scala/C++11 way might make a little more sense intuitively, but it really doesn't help flipping the definitions around.
https://en.wikipedia.org/wiki/Futures_and_promises
The distinction between futures and promises in the wikipedia article matches Scala's terminology exactly.
It's always bothered me that Baker and Hewitt felt the need to coin the term "future" when they were clearly aware of "promise" and "eventual". Their main distinction seems to be that a future is a 3-tuple (process, cell, queue). One can argue that their future meets the "read-only view" definition because cell is only to be written to by the same tuple's process. But they never explicitly distinguish a future as "a read-only placeholder view of a variable," and E was the first publicly-available language to make that very distinction (please correct me if I'm wrong), only they happened to use "promise" in that regard.
In any case, I trust your judgement on the matter more than my own, just wish everyone had picked a nomenclature and stuck with it.