"Additional WebDriver capabilities" vs "extension capabilities" clarification

The terms look a bit confusing to me, so before I start using them in the Generic Sensor spec I'd like to double check I've understood everything correctly.

The way I've read it, other specs are supposed to provide "additional WebDriver capabilities" when necessary (along with a "additional capability deserialization algorithm" and a "matched capability serialization algorithm". These additional WebDriver capabilities must not have ':' in their name.

UAs, intermediary nodes and remote ends, on the other hand, may provide additional "extension capabilities" whose names must include ':'. The WebDriver spec does not put a lot of requirements on how these capabilities are supposed to be serialized or deserialized (there's no "extension capability deserialization algorithm" <dfn>, for example).

• If the above is right, other specifications may provide extension commands and additional WebDriver capabilities, while implementations may provide extension capabilities.
• Does it also mean that, consequently, specs like https://w3c.github.io/webauthn/#sctn-automation and https://fedidcg.github.io/FedCM/#automation are doing it wrong by defining "extension capabilities" instead of "additional WebDriver capabilities" (along with the appropriate serialization/deserialization algorithms)?

Start by reading the WebDriver capability definitions and comparing them with the linked WebAuthn and FedCM automation sections, then check how the Generic Sensor specification intends to use the terms. Done means resolving the terminology question and identifying any specification wording or serialization-algorithm changes required.