Block contains an 80-byte header and a transaction list starting with coinbase. Validity requires both header/Proof of Work rules and content checks; a sufficiently low hash alone is insufficient.
Coinbase comes first. Later transactions may spend earlier outputs in the same block if other conditions are met. Two conflicting spends of one output cannot pass. The Merkle root commits to txid order; witness data also has a commitment through coinbase. [Bitcoin Core v29.0: block validation]
An “empty” block contains at least coinbase, even without ordinary payments. Blocks need not be full. Capacity is constrained by 4,000,000 weight units and other rules, not a fixed payment count; transaction sizes vary. [BIP 141: block weight and witness]
Two valid blocks can share a parent. Nodes choose among valid branches by cumulative work; a block outside the active branch need not be invalid. Reorganizations can change confirmations and UTXO state. One block is not an irreversible finality guarantee. [Bitcoin Core v29.0: block validation]
For the clearest picture, read this entry together with Block header, Transaction, Timechain, Mining. The reverse links also lead from Block header, Merkle tree, Confirmation, Coinbase transaction.