This has obvious disadvantages, but it's a similar pattern as what's already done with autonaming. So, it's just as possible to create new resources using "autonaming" as without "autonaming", at least as far as the second point of the documentation is concerned. The first point is valid and is sufficient to justify "autonaming".

This defintiely has some performance and "predicatability" concerns (like cost predictability that a 3rd resoruce was created). But you are absolutely right it's at least theoretically something Pulumi could have done. Would be great to open a product issue to suggest this (perhaps as an opt-in)? I think though that supporting zero-downtime updates with predictable and "simple" semantics is a true motivation for why we have autonaming by default - so it feels worth noting here. We could add an additional note there about this point that this additional option could have been possible and why we choose not to make it the default (at least not yet!)