Is it acceptable to store state events in addition to action events with the event sourcing pattern?

Considering the following scenario:

An event sourced aggregate manages the transport of a package It can receive commands such as "Package loaded at 5AM", "Package stopped here at 7AM", etc....

The aggregate creates events corresponding to these actions, and from those it computes states like "Package itinerary", "Current location of the package", etc... (those states are also used as building blocks for other states)

Those events are dispatched to read models, but states derived from those events are not.

If I want a read model API to fetch a package itinerary there seems to be two options:

• Share/duplicate the code between the read model and the aggregate, so that given the same events they can compute the same states.

• Have the aggregate work as a state machine so that when the itinerary changes it creates an "Itinerary updated" event with the itinerary attached to it.

  • The event log would look like "tracking created", "some_itinerary_unrelated_event", "package loaded", "itinerary updated", "package stopped here", "itinerary updated", etc....

The second solution seems more practical to me and avoids having to maintain a "shared interpretation" of events between write and read which can become complex if states are built on to of other states.

However this means writing "state events" and seems to go against the "event sourcing is replaying actions to compute states".

What do you think ?