Clients do requests to /nextcloud/ocs/v2.php/apps/... and /nextcloud/remote.php/dav/..., so this might be indeed similar to the /config rewrites in the linked issue, which was fixed only for this particular request.
I can produce the logs when doing requests like:
curl -IL https://my.domain.org/nextcloud/remote.php/dav/
curl -IL https://my.domain.org/nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json
curl -IL https://my.domain.org/nextcloud/ocs/v2.php/apps/user_status/api/v1/user_status?format=json
Getting 401 and 404 (I do not have the user_status app enabled). So any 4xx response seems to lead to a false rewrite. It is not any rule above the #### DO NOT CHANGE ANYTHING ABOVE THIS LINE #### line, as those are not triggered (only apply to requests outside of the Nextcloud dir) and I in fact do not use .htaccess on my personal instance but have those within a dedicated Apache2 config with only those parts relevant with a different base path. The part below that line is also generated by Nextcloud, but dynamically based on the base path.
Requests to core/js/oc.js and core/preview.png do not trigger the errors either, so it must be the last RewriteRule. Strange is that it explicitly excludes /ocs/v(1|2)\.php. Using another excluded path, like robots.txt123, does not trigger the error. Also using /ocs/v2.php does not cause the error, only when further path elements are added. That is true as well for /nextcloud/index.php/123.