It seems that opting out of being treated as thenable is mostly necessary when the presence of the then method is coincidental -- there is a method named then but its purpose is not related to promise resolution.

If that's the case, then the opt-out is necessary because of something about the then method, not something about the object.

Maybe document why/whether adding a marker symbol to the object is preferable to adding a marker symbol to the then method.

A variety of Symbols can be used to change behaviors but are not always exposed / used for exotic objects:

class X {};
Object.setPrototypeOf(X, null);

// undefined, true
console.log(X[Symbol.hasInstance], new X() instanceof X);

Given the abundance of userland promise libraries, is there really a feasible way to un-poison "then"? Having some consumers treat a value as thenable and others not seems worse than just abandoning the property name, placing it in a class with "__proto__" and (in DOM land) form element names that shadow <form> element properties.

It's been very complicated and tricky to optimize the performance of Promises in JavaScript engines. This proposal adds another Get to the Promise resolution path, which could degrade performance further. Is it worth that cost, when there are alternatives like special-casing Module Namespace objects? cc @gsathya

I think there should be a way to configure the key Promise.resolve tries to use for the then-method, instead of simply opting out. Then you could instruct Promise.resolve to check another property and still use 'then' for whatever purpose.

While Symbol.thenable might be more widely useful than just solving the case of import() for the most part the .then-able issue can be solved by wrapping the promise in a trivial object e.g.: { value: somePromise }.

This can't be done for import() (generally even if data: URLs might work in the browser) as the Promise is always created by the host. So I'd propose that a mechanism directly for import() is created that performs this boxing.

I suggested a few mechanisms back in the original issue about dynamic import thenables which could be used for solving this particular case.

The example talks about a .then() method that return a Date instead of a Promise, but how could I do the same when it return a Promise, but don't want to consider it a thenable object?

A real life example (a pitfall I've fallen several times) is when I construct an object that would last some time until it's ready or can fail (for example a network connection) so I add a .then() method on the class resolving to the object itself when it's ready to be used. Problem is, since I'm resolving to a thenable object (the object itself), the .then() method is called again, and I end up in an infinite loop.

class A {
  then(onResolve){
    onResolve(this)
  }
}

new A().then(function(instance){
  // never called
})

Only solution I've found is to remove the then() method once it's resolved, or don't return the this instance. How could this be fixed? Setting the symbol would not prevent to be used as a thenable anymore? Maybe an isNotThenable flag could be added to Promise.resolve() to don't check if the resolved value is a thenable object? This way onResolve would be set to the promise returned by Promise.resolve(), that resolve to a non-thenable object:

class A {
  then(onResolve){
    onResolve(Promise.resolve(this, true))
  }
}

new A().then(function(instance){
  instance.constructor === A  // true

  return instance.then(function(){
    // this should still work since `then` is called directly
    return 'blah'
  })
})
.then(console.log)  // 'blah'