Este comportamiento fue probado en APEX 5.0.0.00.31 y 20.1.0.00.13 al día de hoy, 20 de agosto de 2020, así que es un bug que tiene tiempo dando vueltas por ahí.

Si se añade un APEX item del tipo date_popup a un reporte sin especificar el parámetro p_item_id:

apex_item.date_popup2( p_idx =>1
                     , p_value => sysdate + n)

APEX asignará un ID genérico al elemento, siguiendo el patrón apex_date_idx_row. Para el ejemplo de arriba se tendrá apex_date_01_00, apex_date_01_01, apex_date_01_02, y así sucesivamente. Al llegar al registro #101, se asigna el ID apex_date_01_10 (cuando debería ser _01_101) y se mantiene así hasta el registro #111 que cambia a apex_date_01_11 (cuando debería ser _01_110). Esto hace que APEX no pueda mostrar el botón de calendario que levanta el popup para seleccionar las fechas para ese registro.

Pueden ver un ejemplo del bug acá, moviendose a la tercera página del reporte donde N > 100: https://apex.oracle.com/pls/apex/f?p=28213:5

Parece que APEX está limitando internamente la longitud de ese ID, lo que causa que se pierdan esos números adicionales al final. Recomendaría que revisen sus reportes con elementos que incluyan popups para validar que se estén mostrando correctamente.

La solución rápida es especificar el parámetro p_item_id al momento de crear el apex_item para evitar la asignación automática de este ID.

Quise subir esto al blog para que sirva de referencia futura a quien se encuentre con este problema en el futuro.