Why does nested LOOP AT SCREEN cause infinite loop/recursion?

Question

Here is one for you. Although such a language construction does not make much sense I would like to know why the nested LOOP AT SCREEN cause infinite loop (recursion?).

Let us take the following simple program.

REPORT yyy.

PARAMETERS:
  p_x1 TYPE abap_bool.

AT SELECTION-SCREEN OUTPUT.
  LOOP AT SCREEN.
    BREAK-POINT.
  ENDLOOP.

The BREAK-POINT statement will be executed only 4 times. This leads to an assumption that such a nested loop would run 16 times. Instead the below mentioned program runs forever and ends with a timeout exception.

REPORT yyy.

PARAMETERS:
  p_x1 TYPE abap_bool.

AT SELECTION-SCREEN OUTPUT.
  LOOP AT SCREEN.
    LOOP AT SCREEN.
      ASSERT 1 = 1.
    ENDLOOP.
  ENDLOOP.

It looks like nesting LOOP AT SCREEN causes either an infinite loop or some kind of an infinite recursion.

Why is it so? Is it documented somewhere? The extended check does not report anything regarding the loop. The same applies to Code Inspector as well.

EDIT

I have also checked whether this is a general problem for internal tables with a header line. It seems not.

REPORT YYY.

DATA: gt_t000 TYPE t000 OCCURS 10 WITH HEADER LINE.

START-OF-SELECTION.
  SELECT * FROM t000
    INTO TABLE gt_t000[].

  LOOP AT gt_t000.
    LOOP AT gt_t000.
      WRITE / gt_t000-mandt.
    ENDLOOP.
  ENDLOOP.

Answer 1

There is no practical use of this nested construction, but I have raised a ticket (387728 / 2023) and got an offical answer from SAP:

Nested LOOP AT SCREENS are not supported. Unfortunately this is not captured by an error but usually results in strange behavior of the system, most likely an endless loop.

we will check whether we can (incompatibly) change the system behavior in a way that nested LOOP AT SCREENs will create a runtime error.

So we should conclude that it is officially unsupported feature and as a consequence using it leads to an undefined system behaviour.