>Custom scripts can also modify props (I guess you have this in mind, but >just not to skip it)
That is true. I expect that all calls to "public JMeterProperty getProperty(String key)" should be treated as unsafe. Frankly speaking, it would probably be great if we could split configuration and execution phases. Currently, JMeter uses the same object (e.g. AbstractSampler) to configure the behavior in the test plan, and the very same object is used for the execution. However, the goals there are completely different: 1) Configuration needs backward compatibility (e.g. load old test plans), configuration needs various setters, generic visitor for "search substring" features, and so on 2) Execution needs much less. It does not need UI, it needs no backward compatibility. It just needs enough information to execute stuff. It would be much better if we removed org.apache.jmeter.testelement.AbstractTestElement#setRunningVersion and replaced it with something like `AbstractTestElement#getExecutorNode()` Then we would be able to build the executable test plan just once and skip cloning the test plan nodes altogether. Unfortunately, it is not clear how much effort would it take to rewrite the existing samplers and the controllers to the new approach :( So the plan could probably be like: JMeter 5.3 or 5.4: rewrite org.apache.jmeter.testelement.AbstractTestElement#propMap to use Dexx HashMap; add coroutine-based executor. That would unlock testing with high number of threads. JMeter 6.0: split AbstractTestElement into "configuration" and "execution" classes Vladimir
