nft – Are Mint Passes Just Regular NFTs?

The short answer is that it looks like the latter, unique id for each NFT, regardless of grouping (eg stadium). But to have NFT-like grouping there are a couple of considerations:

The nft example implementation uses an IS_NFT bit for id's with single supplies. Notice that mint uses a packId. Perhaps this can be done more simply for your use case, or you can just use the example code.

And, from the spec's metadata section...

This JSON schema is loosely based on the "ERC721 Metadata JSON Schema", but includes optional formatting to allow for ID substitution by clients. If the string {id} exists in any JSON value, it MUST be replaced with the actual token ID, by all client software that follows this standard.

Which presumably is a cosmetic different to not have large, unwieldy id's.

First, to speak of the "name and symbol" of the "ERC-721 constructor" is not a thing. The constructor is not specified in the standard.

We must understand this question with the context as "what do the name and symbol of the OpenZeppelin Contracts implementation of ERC-721 mean?"

The name and symbol features of ERC-721 are defined in the ERC-721 specification

    /// @notice A descriptive name for a collection of NFTs in this contract
    function name() external view returns (string _name);

    /// @notice An abbreviated name for NFTs in this contract
    function symbol() external view returns (string _symbol);

And further motivation is provided:

We have required name and symbol functions in the metadata extension. Every token EIP and draft we reviewed (ERC-20, ERC-223, ERC-677, ERC-777, ERC-827) included these functions.

We remind implementation authors that the empty string is a valid response to name and symbol if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as your contract. How a client may determine which ERC-721 smart contracts are well-known (canonical) is outside the scope of this standard.