The (Meshes) Overview section of the specification says

Application-specific attribute semantics MUST start with an underscore, e.g., _TEMPERATURE

Some questions are not sufficiently answered by this.

The first question is very vague and hard to answer specifically: What constitutes "application-specific"?

A broader, more specific, and somewhat crucial question is: Is it possible to disambiguate custom attribute names in extensions?

For example, there could be two extensions that both define a generic attribute name like _ID or _VALUE. The name clash would prevent the extensions to be used at the same time. A seemingly simple and straightforward solution would be to require the attribute names to be prefixed with the extension name. Something like "_EXT_foo_bar_ID" looks a bit odd, but is as unambiguous as it gets. In any case: Only requiring the undescore prefix may not be sufficient (also because there is no way to sensibly figure out which extension might already use which attribute names).

A question that is somewhat tangential, but brought up this one (via CesiumGS/3d-tiles#611 ): Can extensions define custom attributes without the _ underscore?

Based on my understanding, the answer to this is no: The validator dedicatedly checks for the semantics that are defined in the core spec, and only skips the ones that start with an undescore, via the checkAttributeSemanticName function, causing a MESH_PRIMITIVE_INVALID_ATTRIBUTE error for all unknown attribute names that do not start with an underscore. But I wanted to ask for a confirmation here: Is it correct that such attribute names would be considered as invalid even when the support for the extension was added to the validator?