What makes a token unique within an ERC-721 NFT contract is that token’s
tokenId. The ERC-721 NFT standard doesn’t tell you how to assign
tokenIds to tokens, but only requires that different tokens have different
tokenIds. If a particular NFT contract allows NFTs to be minted one by one, a simple strategy that will guarantee
tokenId uniqueness is to assign
tokenId = 0 to the first minted token,
tokenId = 1 to the second minted token,
tokenId = 2 to the next minted token,
tokenId = 3 to the next, etc., which is what OpenZeppelin’s ERC721PresetMinterPauserAutoId is doing.
NFT contracts are usually deployed once per collection, so in this case a token’s
tokenId needs to identify a token within the entire collection, as described above. However it is possible to use
1 as a “default
tokenId” as you have suggested, but only if the NFT contract is deployed once per NFT. This isn’t common practice, because in the long run it could end up consuming a lot of gas, but it’s perfectly doable, and there might be scenarios in which such a strategy is preferable (e.g. if you are going to deploy a single special one-of-a-kind NFT, or if you actually required individual NFTs to have their own Ethereum address). Probably if you opted for this strategy of deploying a “singleton NFT contract” per NFT , you’d want to deploy the NFT implementation once, and then deploy a small proxy for every new NFT that would delegate calls to the common implementation.