My understanding of the ERC721 minting process is that it follows three basic steps, it updates the owners balance (mapping _balances), it makes a record, associating the tokenId to the owners address (mapping _owners) and then emits a Transfer event for the tokenId from address 0 to owner. There are also checks done to prevent the same token from being assigned to different owners and vice/versa.
ERC2309 only really explicitly talks about the event, stating that in place of or in addition to the Transfer event being emitted you can emit a ConsecutiveTransfer event. This event is very much the same as the transfer event expect that it announces a block of tokenIds as opposed to one and that block is defined only by a starting and ending tokenId.
The big gas consumers when minting many tokens is the repeated emission of the Transfer event and the for loop needed to update the _owners mapping by assigning the owner address to each tokenId. The ConsecutiveTransfer event solves the problem of repeating the Transfer event. But the problem then remains the for loop for updating the _owners mapping.
Is an explicit mapping of each tokenId to the owner address required at this stage? Or can you adopt the same approach as used by the ConsecutiveTransfer event where all you record is a start and end tokenId and associate the block to the owner address?
Moreover, after this "minting" stage the tokens created are for all intents and purposes fungible. To make the token non-fungible the token meta-data will need to be updated with unique characteristics. Then at that stage you can explicitly assign an owner to the specific tokenId, and you would more than likely be transferring the token from the minter address to a new owner.
Is my interpretation and approach correct? Can this be implemented without breaking the ERC721? Besides needing to write a batchMint function, could one continue to use the rest ERC721, in other words continue to use the Open-Zeppelin implementation for example?