anchor.diff:  
   The default execution mode is applied to all nodes of the test tree with a few notable
   exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
  -`{MethodOrderer}` (except for `{Random}`). In the former case, test authors have to ensure
  -that the test class is thread-safe; in the latter, concurrent execution might conflict
  -with the configured execution order. Thus, in both cases, test methods in such test
  -classes are only executed concurrently if the `@Execution(CONCURRENT)` annotation is
  +`{MethodOrderer}` (except for `{Random}`). In the former case, test authors have to
  +ensure that the test class is thread-safe; in the latter, concurrent execution might
  +conflict with the configured execution order. Thus, in both cases, test methods in such
  +test classes are only executed concurrently if the `@Execution(CONCURRENT)` annotation is
   present on the test class or method.
   
  -All nodes of the test tree that with execution mode `CONCURRENT` will be executed fully in
  -parallel according to the provided <<writing-tests-parallel-execution-config,
  -configuration>> while observing the declarative
  -<<writing-tests-parallel-execution-synchronization, synchronization>> mechanism. Please
  -note that <<running-tests-capturing-output>> needs to be enabled separately.
  +All nodes of the test tree that are configured with the `CONCURRENT` execution mode will
  +be executed fully in parallel according to the provided
  +<<writing-tests-parallel-execution-config, configuration>> while observing the
  +declarative <<writing-tests-parallel-execution-synchronization, synchronization>>
  +mechanism. Please note that <<running-tests-capturing-output>> needs to be enabled
  +separately.
   
   [[writing-tests-parallel-execution-config]]
   ==== Configuration
  
positive.code: specific shared resource that requires synchronized access to ensure reliable test
  execution. The shared resource is identified by a unique name which is a `String`. The
  name can be user-defined or one of the predefined constants in `{Resources}`:
  `SYSTEM_PROPERTIES`, `SYSTEM_OUT`, or `SYSTEM_ERR`.
  
  If the tests in the following example were run in parallel _without_ the use of
  {ResourceLock}, they would be _flaky_. Sometimes they would pass, and at other times they
  
negative.code: example, in `junit-platform.properties` (see <<running-tests-config-params>> for other
  options).
  
  Please note that enabling this property is only the first step required to execute tests
  in parallel. If enabled, test classes and methods will still be executed sequentially by
  default. Whether or not a node in the test tree is executed concurrently is controlled by
  its execution mode. The following two modes are available.
  
  `SAME_THREAD`::
    Force execution in the same thread used by the parent. For example, when used on a test
  