After WFCORE-6490, a customer's previously working configuration as in the one attached that removed the "default" io worker can now fail if continuing to use io subsystem scheme 3.0 or earlier:

    <subsystem xmlns="urn:jboss:domain:io:3.0">
      <worker name="ama-thread-pool" task-max-threads="200"/>
      <buffer-pool name="default"/>
    </subsystem> 

As it hits an error like below:

10:40:04,976 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=io' are not available:    org.wildfly.io.worker.default; Possible registration points for this capability: 		/subsystem=io/worker=* 

But the same settings then work if just changing the scheme to the latest 4.0 still with no value given for the new default-worker attribute:

    <subsystem xmlns="urn:jboss:domain:io:4.0">
      <worker name="ama-thread-pool" task-max-threads="200"/>
      <buffer-pool name="default"/>
    </subsystem>  

Such an inconsistency seems a bit odd and looks to be from https://github.com/wildfly/wildfly-core/blob/584c16ea5223a12af991d17e9b529f6f1e461e49/io/subsystem/src/main/java/org/wildfly/extension/io/IOSubsystemSchema.java#L55 forcing the default-worker to a value of default for scheme 3.0 and earlier while 4.0 allows it to be unspecified.  Should we really force "default" to be used on 3.0 particularly when the "default" worker may not even actually exist?  Could 3.0 also use an 'unspecified' value by default like 4.0 or at least do a safety check to ensure the "default" worker actually exists if it is forcing that value for the 'default-worker' so we don't fail previous configurations?