views_ajax_render() has been removed.

Both those paths only get executed if ViewExecutable::setDisplay() returns FALSE, which seems like a rare, perhaps impossible, occurrence in these cases. The other calls to setDisplay() in \Drupal\views_ui\Form\Ajax\* don't bother checking the return value and just assume it succeeded.

Not sure how to test this.

+++ b/core/modules/views_ui/src/Form/Ajax/RearrangeFilter.php
@@ -41,9 +41,7 @@ public function buildForm(array $form, FormStateInterface $form_state) {
-    if (!$executable->setDisplay($display_id)) {
-      views_ajax_render($this->t('Invalid display id @display', array('@display' => $display_id)));
-    }
+    $executable->setDisplay($display_id);

Can we maybe still throw some exception, or call a drupal_set_message with that old message?

ViewExecutable::setDisplay() returns FALSE, which seems like a rare, perhaps impossible, occurrence in these cases

This is not entirely true. Views always tries to assume that a display might not be available, especially in the UI. You still need some basic way to be able to at least remove the broken display.

In this case these forms are child panes of the main Views edit UI (aggregation settings and filter reordering respectively) where a valid display will always be present; I don't see a way of triggering these forms from an invalid display. As far as I can tell ViewEditForm will always be displayed first with the same display, and that does check the result of setDisplay() and bails out early if it is invalid. There are five other Ajax form panes that already do not bother checking the result of setDisplay().

Here's an alternative that shows a text "Invalid display id foo" but I agree with #5, can't find a way how to trigger this error via UI (except visiting admin/structure/views/nojs/rearrange-filter/content/foo).

For consistency if we are to add the message as in #5 we should do it across all the Ajax form classes.

Here's #7.

Here's an alternative that shows a text "Invalid display id foo" but I agree with #5, can't find a way how to trigger this error via UI (except visiting admin/structure/views/nojs/rearrange-filter/content/foo).

Well, this is not the point. The problem is that you should be able to somehow fix in the UI it if it fails to initialize the display.
Still i think it could be testable. ALter the config file manually ... and check whether you can still remove it via the UI.

Patch #8 needs to be updated.

Here is the updated patch.

Thanks! This still needs tests.

Let's see if I come up with an test.

I found this very challenging to find a way to test this (as raised in #5 and #6) and not sure where to put this test or should I create new test case completely, but hopefully this takes this issue further.

Attached new patch with test example, interdiff (the test only) and a patch having the patch only without the patch above (to test whether it passes/fails as should.

That looks like a reasonable place for the test but you could also put it in a new test function. Anyways I'll leave this to someone else who knows if it's enough tests.

Putting the test in a new method would trigger an entire install since this extends WebTestBase.

I think this is RTBC. I've added a beta phase evaluation to the issue summary.