I’m on the side of ‘Use the Process Dictionary when it makes sense’. It is often easier to use the process dictionary to store and access ‘context constants’, like the pid of a parent or a user’s name or ID that will never change in the current context, and those processes die at the end of the context so they do not linger. Mutable state or it’s side effects caused by changes to Process Dictionary can be an absolute nightmare to debug. In your case being used from a single process as mentioned could be very difficult without care, what if two instances were being used in the same process for example.

So far, I’ve followed the best practice of always passing this state around as arguments rather than using the process dictionary.

I think I agree that there is some cumbersomeness with having to pass a state term to APIs even though in some cases it might not be used, and further returning it from all library functions. Consider this: passing the state and returning the state even if the library might not actually use it is easier for to remember than ‘Does this API require the state object or not…’. A consistent interface is useful.

The alternative to returning the {state, value} tuple is to use getters and having the state object perform all tracking:

state_new = OpenAPI.Processor.Type.from_schema(state_old)
value = OpenAPI.Processor.Type.get_schema_value(state_new)

discourage any manual editing of the data

Good luck

Then shouldn’t you just use a GenServer and hide the state from the outside?

An “intermediate” storage strategy might fit better: keep an ETS table (or several) that are passed into functions.

That would give the same “implicit write everywhere” mutability as the process dictionary, without the exactly-one-per-process limitation.