This reveals internal bits to the client which is already very bad since it would break expected behavior down the line if any of this ever changes, but on top of that this code is all wrong, which makes me thing that it wasn't actually tested.

The purpose of this PR is to have feedback on what can be done. I already have open PR before https://github.com/citizenfx/fivem/pull/1896/files with non constructive discussion.
Tested but not in production since it was tested without adhesive
Keep in mind c++ is not my main language

I understand why some might find a functionality like this useful. However, I don't believe it's a viable solution to the core issue of the limited number of players a client can process.

While the internal overhead introduced by the bit-tests might be acceptable, the overhead in ScRTs could be problematic. For instance, if someone uses this feature to implement custom culling with prioritization for players near a target client, it would necessitate high-frequency updates and checks. This would involve invoking different natives for each player, which could significantly impact performance on servers with higher player counts (where such functionality would be most needed). Given that these servers often already struggle to maintain the target tick rate, this approach could potentially only worsen the situation.

The main issue is to not slow down the sync thread to prioritise culled players. you have more advanced knowledge on the subject. How we can achieve this decently ? Can we try in production with beta build like It’s done in experimental forum ?

It will most likely create ownership issues for entities controlled by "out-of-scope" players
Just like what the culling natives often create btw

We already have ownership issue with curling radius, and we deal with it with workarounds

That isn't exactly a good reason to add something else that could lead to more unknown/weird issues.