After much thought, I came to a realization that our current architecture is insufficient for future advancements.

There are a few key problems with the current design:

• Event handling is inadequate: we cannot make any guarantees about what happens between when an event is triggered and when it is handled. As a result, it becomes difficult to implement certain features. For example, once we handle item uses, the likely path we would take is to add an ItemUseEvent which stores the item type, then create a system to handle the event for each item type. The problem here is that between when the event is triggered and when the handling system runs, the item which was used could be removed or replaced with another item. If the handling system fails to acknowledge this, then it could end up mutating the new item in an undesirable way, such as by removing it.
• There is no way to dynamically schedule systems for running. In the case of commands, for example, creating a system handling CommandEvents for every single command is impractical. Ideally, command handlers with arbitrary resource access could be stored in a map, and the system which handles commands could schedule these handlers to be run in this tick.
• There are many signs that the development of Specs is diminishing. The primary maintainer recently quit the project, handing it off to the Amethyst organization.. However, the Amethyst project is planning to transition from Specs to Legion, so we cannot expect them to develop Specs in the future.

I propose two key changes to solve this problem:

• Eliminate Specs and transition to Legion as Amethyst is doing. In addition to its more active development push, Legion has superior iteration performance to Specs due to its archetype-based design. Their model also improves cache locality of components. See this discussion for more information on the benefits of Legion.
• Rather than Legion's system scheduler, which is similar to Specs's, we will use tonks, a project which I have been working on for the last while. This is an alternative system scheduler which acts as a solution to the first two problems mentioned above. It will support reactive event handling and dynamic scheduling of "oneshot" systems to meet our needs.

Do note that these changes will require a rewrite of all systems in the codebase. The majority of the codebase, however, is infrastructure such as worldgen, networking, and the chunk implementation, so this is not a complete rewrite of Feather.

If anyone was wondering why Feather development has slowed recently, this is why. Once tonks is complete, I plan to begin the transition.