Before you can read a single line of the parent note, you must already own a small pile of ideas: what a source file is, what compiling even does, what a macro is, what "a name is visible" means. The parent note quietly assumes all of them. This page builds every one from the ground up, in the order they depend on each other.
Look at the figure. On the left is one text file. The compiler cannot run text — it must first translate it into machine instructions. That translation is the next idea.
In the figure, the file main.cpp on its own is small, but after #include pastes header text in, the translation unit balloons. That ballooning — the same header text copied into hundreds of TUs — is problem #1 the parent note lists ("slow builds"). This idea is so central it has its own vault note: Translation Units and Linkage.
Because #include is paste, two files that both include the same header get two copies of every declaration — which is why the old world needed include guards (a #ifndef trick to skip the second paste). Modules delete this whole headache; that is the parent's "No guards needed" row.
Modules do not carry macros across import. That single fact is why the parent celebrates "Macros do not leak." You must know what a macro is to see why not-leaking is a win.
The figure shows three nested visibility rings. This ring picture is exactly what the parent's biggest mistake callout is about: export and public are different rings.
public / private — an inner ring: which class members other code may touch.
export — an outer ring: which file-level names cross the module boundary to importers.
A private member of an exported class is exported-as-a-class but still privately sealed — two independent rings, both must open for you to reach it.
