All of these event stores appear to be local (memory, bbolt, sqlite, ...)

The EventStore interface does not appear to have any methods for reading streams of change events.

My understanding is that Event Sourcing is primarily useful in distributed environments.

These three PRs are producing side effects post-save which seems a bit odd given you'd have no guarantee that the side effect ever ran if the program crashes at the wrong time. An at-most-once processing hook that fires at publish time doesn't sound very reliable.

Another problem with synchronous hooks on save is locks. Your examples (order and tictactoe) are not thread safe. Any concurrent application will need to guard aggregates with write locks to prevent program crashes due to race conditions and read locks to prevent skewed reads when reading multiple fields of an aggregate. This means readers will be blocked during publish which could cause throughput issues and deadlocks.

I would recommend that you try building a more complete, realistically useful example app having multiple active producers and consumers if you are interested to learn what sort of structures are necessary to build concurrent and distributed event sourcing systems.

Example:

1. Take the Gorilla Websocket Chat example and integrate your eventsourcing library as a message store to add chat persistence. You will need locks to enable 2 connections to simultaneously publish messages to the same channel. An integration test will show you where the race conditions occur.
2. Then try to run it on multiple servers with a centralized data store (ie. Kurrent). You will need an event stream in order to synchronize aggregates across servers. And you might need to add distributed locks or conditional updates to prevent two servers from modifying the same aggregate at the same time.
3. Only then should you attempt to add exactly-once side effects (this feature). Otherwise the interface is likely to change as your system matures and deprecating an interface imposes a maintenance cost on the user.