Initially settings for capabilities. Specifies which legacy role every individual capability applies to with the "allow" setting.
The settings are located in the files moodlerootdirectory/mod/modulemap/db/access.php
Every module has its own legacy settings for its capabilities (except modules with pre 1.7 code).
A) Body of capabilities that have capability settings passed from LEGACY settings
B) A construction that work with pre 1.7 code.
A LEGACY role is not a role and is not to be mixed up with normal roles.
If you are using any third party code you may have other LEGACY role definitions than if you are not, while the LEGACY role definition is specified dependent of your actual Moodle installation and it's (possibly) current add ons/active modules.
Moodle have 6 types of LEGACY capabilies:
Happens by definition to be equal to the capabilities for the predefined default roles.
Due to surviving pre 1.7 code it can have fatal consequences to remove a role's legacy capability.
All though all the capabilities of the body are not removed when the legacy capability are removed, old code may have functioning capabilities that are not defined as capabilities in the nowaday's meaning of the word, but that gets triggered by a pre 1.7 code call to the legacy capability body (called legacy role). The other way round NOT removing a legacy code can (due to pre 1.7 code) be an obstruction for edited permissions to become effective. See John's example with the guest role in this discussion. This problem goes for the legacy role teacher too (Petr Škoda in the tracker).
About the terms:
It has not been easy to get this far. Especially the term role used when it is a capability is confusing, and confusing is the term Iegacy too. In addition the predefined roles are not called default roles all though they are (as far as I can see). Instead they are very easy to mix up with legacy roles.
Here I have introduced a term capability body, could that be used?