While not a strictly critical issue, the absence of system set re-configuration is quite unpleasant. The option to disable systems is good, but sometimes it's preferable to spawn and kill systems entirely. In Ashley, it usually goes hand in hand with EntitySystem#addedToEngine(Engine)/EntitySystem#removedFromEngine(Engine) and is very convenient for resource management. Systems do not always operate over entities (e.g. IntervalSystem).

One good use case could be to toggle debug rendering for a limited time. Here's what it could look like:

class DebugRenderSystem : IteratingSystem(family { ... }) {
    val heavyRenderBatcher = new()
    val heavyInternalResource = new()
    
    // ...
    
    override fun onDispose() {
        super.onDispose()
        heavyRenderBatcher.dispose()
        heavyInternalResource.dispose()
    }
}

Systems like this borrow unnecessary resources when they are not enabled and it's easier to just spawn and destroy them when needed. Conditionally creating and accessing such systems during world initialization may look rather dirty too.

This also highlights a little problem of missing a mirrored pair to onDispose() (onInitialize()?). It's always good to have such mirrored events to acquire/free resources. The system's constructor is not always the best place, as the world is not yet initialized at this point and some required objects may not be available yet (like other systems, that get added after the current one). In general case, it would be good to have that onInitialize() method right before the first onUpdate() hits. But that of course can be achieved without the library modification.

And lastly, dynamically modifying systems also brings the necessity of order control. Currently, the system set is static, the order is pre-defined, and there's obviously no need for extra sorting. But if systems can be added later, obviously, having the option to put them in the right place is crucial.