Unfortunately this in its current form will not have the desired effect.

The loading of term definitions is cumulative. Therefore the re-specifying of enumerations such as ActionStatusType within the issue-2604.ttl file has the effect of adding new triples (for differences between the original definition [in data/schema.ttl] and the new one] not overriding them.

The impact in this case is twofold:

1. The redefined terms such as ActionStatusType cause the term to now be subClassOf both Enumeration and StatusEnumeration.
2. Differences in definition throw up extra triples - for example GameServerStatus has two differing comment triples. This is causing the scripts/run_tests.py to fail, and the integration tests to fail on the PR, with the following error:
   type 'GameServerStatus': Expected 1 rdfs:comment, found: 2.

Recommended actions:

• Remove definitions of existing enumerations from the issue-2604.ttl file, leaving only the definition for StatusEnumeration.
• Update the rdfs:subClassOf value to be :StatusEnumeration in their original locations (data/schema.ttl) for the enumerations in question.
• Run the scripts/run_tests.py script prior to updating the branch associated with the PR

So (2.) extra triples is just a glitch because of an accidental rdfs:comment, i.e.

:GameServerStatus a rdfs:Class ;
    rdfs:label "GameServerStatus" ;
    :category "issue-2604" ;
    :isPartOf <http://pending.schema.org> ;
    :source <https://github.com/schemaorg/schemaorg/issues/2604> ;
    rdfs:comment "" ;

I am less clear on (1.), @RichardWallis -- are you saying that enumerations shouldn't form subclassof hierarchies? Aren't we doing that in the case of the benefits codes in #2543 ?

i.e. we have in ext/data/pending/issue-2543.ttl

:UKNonprofitType a rdfs:Class ;
    rdfs:label "UKNonprofitType" ;
    :category "issue-2543" ;
    :isPartOf <http://pending.schema.org> ;
    :source <https://github.com/schemaorg/schemaorg/issues/2543> ;
    rdfs:comment "UKNonprofitType: Non-profit organization type originating from the United Kingdom." ;
    rdfs:subClassOf :NonprofitType .

and

:NonprofitType a rdfs:Class ;
    rdfs:label "NonprofitType" ;
    :category "issue-2543" ;
    :isPartOf <http://pending.schema.org> ;
    :source <https://github.com/schemaorg/schemaorg/issues/2543> ;
    rdfs:comment "NonprofitType enumerates several kinds of official non-profit types of which a non-profit organization can be." ;
    rdfs:subClassOf :Enumeration .

Or more compactly:

• :UKNonprofitType a rdfs:Class ; rdfs:subClassOf :NonprofitType .
• :NonprofitType a rdfs:Class ; rdfs:subClassOf :Enumeration .

... and then from rdfs:subClassOf we can conclude that :UKNonprofitType is also an rdfs:subClassOf :Enumeration too.

What am I missing here?

(@RichardWallis I should say that I do get the point that re-defining stuff from core i.e. data/schema.ttl in an overlay data/ext/pending/*.ttl file is going to produce confusing results, but your specific point about the classes confused me)

My understanding of the proposal [picking just one of the enumerations as an example] is that instead of being a direct descendant (rdfs:subClassOf) :Enumeration ActionStatusType will become a decendant of a new enumeration :StatusEnumeration.

With the current status of the PR, ActionStatusType is defined as rdfs:subClassOf :StatusEnumeration in the file issue-2604.ttl and rdfs:subClassOf :Enumeration in the file schema.ttl.

The effect being:

As can be seen, ActionStatusType is still a direct subtype of Enumeration. Not what is wanted with the objective being "to prevent a combinatorial explosion of enumerated items in any enumeration list." presumably, that includes the list for Enumeration itself.

To fix this, either the rdfs:subClassOf :Enumeration line needs deleting from the definition in schema.ttl; or preferably it needs changing to rdfs:subClassOf :StatusEnumeration and the whole definition for ActionStatusType removing from the issue-2604.ttl file.

This pattern is the same for all the other enumerations that are to be moved to be subtypes of StatusEnumeration.

Merging, but noting @rjw concerns above; will edit post-merge.