The implementation details of the store and env are not relevant to the CESKM step algorithm. The env and store should keep their default implementations as straightforward Record<string,_> definitions but this should be customizable in sub classes which may wish to present the step function with an object fulfilling the same API but backed by, eg, a persistent data store.

As well, CBPV and coeffects both augment the usual binding environment with extra data.

Overall, as a rule of thumb

• step function algorithm line count shouldn't change
• CESKM type should have more generic type params governing env and store, which default to current simple definitions