@nonreentrant Decorator vs Manual Boolean Guard for Vyper Reentrancy Protection

Context

When securing state-changing external functions in Vyper against reentrancy, two documented patterns exist: the built-in @nonreentrant decorator and a manually managed boolean state variable. The decorator reserves a storage slot and reverts on reentry, while a manual guard offers custom revert or skip logic but demands discipline across every exit path.

Constraints and Uncertainty

The decorator is function-scoped, so each vulnerable entry point must be decorated individually, and it does not automatically extend protection to other functions. A manual guard risks leaving the contract permanently locked if an exception occurs before the flag is reset, unless every revert path clears the variable. Both approaches add storage reads and writes, increasing gas relative to unprotected functions, with exact costs varying by Vyper version and EVM schedule. Additionally, @nonreentrant may be unavailable in older compiler releases, and neither pattern addresses cross-function reentrancy unless all interacting entry points are protected consistently.

Questions

1. For a contract targeting Vyper 0.3.x, does the gas overhead of @nonreentrant differ materially from a well-implemented manual guard across typical state-changing functions?
2. When cross-function reentrancy is a concern, which pattern composes more safely with a shared lock variable without introducing deadlock risk?
3. Are there version-specific semantics in @nonreentrant (e.g., error message, storage slot allocation) that would make a manual guard preferable for long-term maintainability?