You're right, and it's the sharper version of the point that section was making. I framed the matching column as an identity key without saying that the key is only enforced by a lookup, and a lookup that happens before the write isn't enforcement at all. Read-then-write with no conditional write on the API side means two runs can both pass the check.
One correction to the fix, because I went to check before adding it: concurrency in n8n isn't a per-workflow setting. N8N_CONCURRENCY_PRODUCTION_LIMIT caps concurrent production executions instance-wide, in both regular and scaling modes, and defaults to -1 (no cap in regular mode). So setting it to 1 serialises everything on the instance, not just the workflow that needs it — cheap, but blunter than it sounds. I couldn't find any per-workflow equivalent in the docs.
Which makes your second point the real one: if the key has to hold, it belongs somewhere that can refuse the second write. A unique constraint in Postgres does what a sheet structurally cannot.
I've added this to Build 3 as a third limit, credited to you.
Build 3 describes the matching column as an identity key, and it behaves like one right up to the moment two executions run at once. Append or Update reads the sheet to find the matching row and then writes, and the Sheets API has no conditional write to make that a single operation. Two runs carrying the same key both look, both find nothing, and both append: the duplicate the node exists to prevent.
It stays invisible at low volume and appears the first time a webhook fires twice or a batch runs in parallel. Concurrency 1 on that workflow is the cheap fix; a unique key in something that can refuse a second write is the durable one, because the sheet cannot.