Short answer: You can’t safely do this any more. NDSolveStateData is now an opaque object that contains internal handles (e.g. InternalBag) whose identity has to be preserved. Any attempt to “crack it open” and rebuild it (including via the loopback-link Hold/ReleaseHold trick) will create new internal objects that no longer match the other references inside the state. That breaks NDSolve’s invariants and can crash the kernel. The right way to change things like the finite-difference order is to specify them up front via options and rebuild the state, not to mutate an existing state.

Why the loopback trick fails

• Modern NDSolveStateData (and related objects like NumericalFunction) aggregate internal state via identity-based handles (InternalBag and others).
• Serializing through WSTP (LinkWrite/LinkRead) and then ReleaseHold recreates a new Bag (ReleaseHold[holdbag] =!= bag in your minimal example), so all identity relationships are lost.
• After such a reconstruction, sub-objects refer to different internal handles than other parts of the state expect; the invariants are violated, and using the object (especially in ProcessSolutions) can crash.

There is no general safe way to modify the internals of NDSolveStateData in place. The crash itself is still a kernel bug (the kernel should not crash), but because you’re using undocumented internals, there’s no compatibility guarantee. If you want, you can report a minimal reproducer (the InternalBag case) to Wolfram Support.

What to do instead

• Specify discretization options at construction time. For your example, set the difference order in the spatial discretization method when you call NDSolve or NDSolve`ProcessEquations:

  Method -> { "PDEDiscretization" -> {"MethodOfLines", "SpatialDiscretization" -> {"TensorProductGrid", "DifferenceOrder" -> 2 } } }

Example:

tmax = 10; lb = 0; rb = 5; system = With[{u = u[t, x]}, { D[u, t] == D[u, x, x], u == 0 /. t -> 0, u == Sin[t] /. x -> lb, u == 0 /. x -> rb }];

{state} = NDSolve`ProcessEquations[ system, u, {t, 0, tmax}, {x, lb, rb}, Method -> { "PDEDiscretization" -> {"MethodOfLines", "SpatialDiscretization" -> {"TensorProductGrid", "DifferenceOrder" -> 2 } } } ];

NDSolveIterate[state, tmax]; sol = u /. NDSolveProcessSolutions[state];

• If you need to change something that cannot be set post hoc via supported APIs, rebuild the state with the desired options rather than trying to mutate it. In practice that means keeping around the equations, domains, variables, and method options you used to construct the state and calling NDSolve`ProcessEquations again with the new settings.

Notes

• Some limited run-time changes are supported via functions like NDSolveSetOptions or NDSolveReinitialize, but those do not include changing the spatial finite-difference order. Treat those as internal/unsupported as well unless explicitly documented.
• Avoid relying on the internal structure of NDSolve`StateData, NumericalFunction, FiniteDifferenceDerivativeFunction, etc. Their internal representation and mutability changed across versions (as you observed), and those changes are not guaranteed to be compatible.

Bottom line: Don’t try to modify NDSolve`StateData in place. Use the documented method/options to get the discretization you want, and reconstruct the state if you need to change them.