This document describes a few design considerations, for the main specification, refer to the README document.
We are explicitly not providing a chainable method, thus we are also not recommending to chain them, but rather to use coroutines in form of generators inside application code.
Coroutines solve the problem of the so-called callback hell very nicely and also allow proper usage of try / catch.
The specification proposes when() in order to only expose the most primitive common denominator needed for interoperability, which is a simple callable to be executed after the resolution.
If implementations wish to adhere to e.g. Promises/A+ from Javascript (which had been implemented in many PHP Promise libraries at the time of writing this specification) or implement any other methods, they still may do so; when() however is the fundamental interoperable primitive every Promise is guaranteed to have.
Additionally, coroutines do not use the returned Promise of a then() callback, but returning a Promise is required by Promises/A+. Thus there's a lot of useless object creations when using Promises the recommended way, which isn't cheap and adds up. This conflicts with the goal of being as lightweight as possible.
Promise is a recognized and accepted name for future value placeholders, it's not strictly tied to the Thenable API.
Promise creation and managing is out of scope of this specification, as managing never shall cross library boundaries and thus does not need to be interoperable at all. Each library shall resolve the Promise it created itself.
The specification defines that the value of a Promise must never be another Promise. Implementations may still accept to be resolved by a promise and then defer the resolution until the passed promise resolves.