Legacy MPxNode plug-ins defaulting to parallel evaluation: what are the actual limits and risks?

I'm auditing a set of older C++ plug-in nodes (compiled against pre-2016 Maya APIs) that are now loaded in a modern Maya version where the Evaluation Manager runs in parallel mode by default. These nodes predate MPxNode::evaluationMethod(), so they cannot declare kSerial or kDefer — as I understand it, they silently fall back to kParallel.

Some of these nodes access shared state inside compute(): static caches, non-reentrant third-party libraries, and in one case file I/O. The documented contract says compute methods "should be thread-safe," but there appears to be no load-time enforcement, no runtime sandbox, and no automatic serialization for nodes that violate it.

My uncertainty is about the practical boundary of what Maya guarantees here. The Evaluation Manager UI reports parallel vs. serial node counts, and the Evaluation Graph Profiler shows region boundaries, but neither seems able to identify which specific custom nodes are unsafe — only the global serial-mode workaround, which costs significant rig performance.

Specifically:

• Is the default-to-parallel behavior for legacy nodes without evaluationMethod() consistent across Maya 2019 through current releases, or did the conservative heuristics change the fallback?
• Short of recompiling, is there any per-node mechanism (attribute, plug-in metadata, Evaluation Manager override) to force an individual legacy node into serial scheduling?
• What is the recommended way to attribute a race condition to a specific node when the profiler cannot flag unsafe memory access?