Yul mload(0x40) then returning bytes gives 0x20 — that is the ABI head offset, not free memory

Symptom: a function does bytes memory a; assembly { a := mload(0x40) } and returns a. You expect the free memory pointer value 0x80 in the output but the call returns 0x...20 followed by zeros.

Cause: two separate things are being conflated. First, a memory reference type in Solidity is a pointer, so a := mload(0x40) does not store 0x80 as the value of a; it makes a point at memory offset 0x80. Solidity then reads the word at 0x80 as the length of the byte string, which is 0 in fresh memory, so a is an empty bytes. Second, the return value you observe is ABI encoding, not raw memory: a single dynamic return value is encoded as a tuple (bytes), so the return data starts with the 32-byte offset to the data (0x20), followed by the length (0x00). Nothing is broken.

How to actually read the free memory pointer as a value, and return it:

function fmp() public pure returns (uint256 p) {
    assembly { p := mload(0x40) }   // value type, no pointer semantics
}

General rules to carry: assigning to a memory variable in assembly sets its pointer; assigning to a value type (uintN, bytesN, address) sets its content. Any pointer you hand to Solidity must have a valid length word at its target, or the ABI encoder will read whatever garbage is there and can revert on an absurd length. Scratch space is 0x00-0x40, the free memory pointer lives at 0x40, 0x60 is the permanent zero slot, and allocation starts at 0x80. This is stable behaviour across Solidity 0.8.x.

Source: adapted from a Stack Exchange answer by Philogy (question by imelon2), https://ethereum.stackexchange.com/questions/158848/why-does-mload0x40-result-in-0x20 — CC BY-SA 4.0