These changes are just because declare is not syntactically allowed in that position (it's required to be at top level). Just some hygiene, not relevant to the changes.

surprisingly, assignments without a declaration were not tested for

I'm not a community maintainer, but I'm very much against these tests.
Even, after checking off all the options in the type-checking section, typescript is still giving error on this statement.

Playground link

Either these tests be removed or should be replaced with valid ts code.

Relevant: #8298

+1 that if we can get away with no type error, it'd be better to.

const value = {};

value as Promise<number>;

Makes sense. Also, very clever with suggesting the castable {} 👍

The empty object type has been on my mind a lot lately... 😂

In your summary you wrote

Changes implementation from an unhandled promise syntax allowlist to a syntax denylist.

But I don't understand what we gain from that switch

This seems... dangerous - switching to default assuming it's unhandled is probably going to lead to false positives at scale.

TL;DR Concern is valid but I tentatively think this is the right move. Would welcome a second opinion

I don't understand what we gain from that switch

implementation simplicity and future proofing 🤷 It seems more straightforward, and more correct (IMO), to opt out of flagging behaviors indicated by the docs than it does to opt in to the ones we do want to flag...

Nodes that are handled

• await expression
• assignment expression (x = y)

Nodes that require special handling to determine whether they're handled or unhandled (and therefore need to be specified individually no matter what)

• CallExpression
• LogicalExpression
• SequenceExpression
• ConditionalExpression
• void expression
• optional chaining expression
• iifes

Nodes that are always unhandled (if they result in a promise)

• NewExpression
• Identifier
• MemberExpression
• TaggedTemplateExpression (previously forgotten, recently fixed in fix(eslint-plugin): [no-floating-promises] handle TaggedTemplateExpression #8758)
• TSAsExpression (previously forgotten, the point of this PR)
• TSTypeAssertion (previously forgotten, the point of this PR)
• TSNonNullExpression (previously forgotten, basically equivalent to previous two)
• ... probably more - this feels like the appropriate default behavior for anything that doesn't fall into one of the other two buckets

This seems... dangerous - switching to default assuming it's unhandled is probably going to lead to false positives at scale.

To be sure, I gave this some thought before making this change, and I just couldn't think of any scenarios where this would really be problematic... Every case I thought of seemed to be beneficial. Just to be sure we're on the same page, that code is only reached if the expression results in a promise/thenable.

That does mean that this code will start flagging now

({
  then(resolve: Function, reject: Function) {
    return this;
  }
});

and I think that makes sense, given

const unhandled = {
  then(resolve: Function, reject: Function) {
    return this;
  }
};
unhandled;

already flags (of course, this touches upon #8433). But it's not like we're suddenly going to flag every object literal; just thenable ones.

I think the yield cases added to the tests make sense to flag as well....

Note that we dogfood no-floating-promises in this repo and this change didn't result in any new reports.

My conclusion - false positives are a very valid concern to explore, but for now I do think that this change is safe/beneficial. Would definitely be open to being proven wrong, though, especially if a good counterexample comes to mind! 🙂