Sure, let's close it.
The attached patch fixes the failure. It also removes usage of the runtime service.
Dmitriy.trt → created an issue.
Just a reroll of #6 on 2.x. It's applicable to 2.2.0 as well.
An updated version of the #29 patch is attached. It should be compatible with both Drupal 9 & 10.
Considering questions of #26, it requires some changes. And, it would be nice to have tests for the feature it adds. Unfortunately, I don't have time for it at the moment.
Just merged the latest changes from the 5.0.x branch, and fixed multiple test failures on PHP8.1 & D10 (see diff).
Dmitriy.trt → made their first commit to this issue’s fork.
Just created an MR!3 with the automated fixed from #3 and a few additional fixes for compatibility with Drupal 10 (see diff).
Unfortunately, the compatibility fixes raised the minimal core version to 9.1. Earlier core versions could be supported with a few additional checks, but I'm not sure if this is really needed.
Side note. No idea what happened with the initial 3288146-automated-drupal-10 branch in the issue fork. Drupal.org just didn't create it. So, I had to create another one.
Dmitriy.trt → made their first commit to this issue’s fork.
Just opened an MR!2 with Drupal 10 added to the core_version_requirement. There is really no need to remove the core entry. The module could support older Drupal 8 versions and Drupal 10 at the same time.
Dmitriy.trt → made their first commit to this issue’s fork.
Submitted an MR!2 with the patch of #3 and a few more compatibility fixes (see diff).
There is no need to drop Drupal 8 support as tests pass on D8 too.
Dmitriy.trt → made their first commit to this issue’s fork.
Created 2.x branch for the next major version of the module. It will support Drupal 9 & 10 only. The patch from #2 is applied there, in addition to other D10 compatibility fixes.
Adding a diff file here for a stable reference from composer files. It was made from MR !1148 at commit 972afa7c.
Submitted an alternative MR !1148. The issue it resolves is described in #134.
Another option is to make a sub-request to the form route. This way AJAX should also work on the condition form.
It looks like current approach doesn't allow a condition plugin to use AJAX on its configuration form. Just because the form is rendered on a route where it doesn't exist here. And it's also the reason why its #action has to be rewritten here.
An alternative would be to list condition types as AJAX-enabled URLs instead. This way there must be no issue with AJAX on the condition settings form.