This has been tested on APEX 5.0.0.00.31 and 20.1.0.00.13 as of August 20th, 2020, so it has been around for some time.

If you add a date_popup APEX item to a report without setting the p_item_id parameter, like this:

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

APEX will assign a generic ID for the input in the form of apex_date_idx_row. So for the example above you will have apex_date_01_00, apex_date_01_01, apex_date_01_02, and so on. When you reach row number 101, it assigns apex_date_01_10 (instead of _01_101) and stays like that until row 111 where it changes to apex_date_01_11 (instead of _01_110). This makes APEX fail to be able to render the calendar box to the side, so the popup is unusable for that row.

You can see a quick example of the issue here, moving in the pagination until you reach N > 100: https://apex.oracle.com/pls/apex/f?p=28213:5

APEX seems to cap the length of that string and this causes the missing extra numbers at the end. I would check any of your reports that use popups to validate the correct rendering of the extra elements of the inputs.

The quick solution is to specify p_item_id when creating your apex_item to avoid using the generated ID.

I just wanted to put this up here, in case someone finds this useful in the future.