Let's make the problem clearer with a constructed example.

Let's suppose we need to test an app with random points on earth.

First approach

The point is calculated by randomly picking an first Y coordinate and than a legal X into 2D maps projecting of both hemispheres onto circles.

Here an image of western and eastern hemisphere from Hemispheres_of_Earth

This would be fundamentally flawed because there are far less legal X coordinates near the polar circle, IOW the result is biased b/c points in the equatorial region are underrepresented.

Second approach

Let's say we repeat Y,X picking randomly and only check afterwards till it's inside the circle. Now every point in the 2D projection has the same likelihood. But this is still flawed because the projection from 3D is flawed by itself.

Third approach

One way to guaranty that every square meter on earth has the same likelihood (if required) is to be pick polar coordinates (but only in a special way and ignoring that the earth is more a potato than a perfect sphere )

Combinatorics

So far the geometrical example.

But combinatorial structures from the OP are far more complicated. °

The random picking demonstrated so far in code examples in this thread will mostly be "flawed", because certain results will be far more likely than others. Some will even be skipped.

I've put "flawed" in quotes for a reason. It's perfectly possible that imperfect random input is just good enough.

That's why we need to ask "How random is random enough"

°) A more obvious example is adding the results of two dices to construct a random number between 2 and 12. The result 6 =1+5 = 2+4 = 3+3 = ... would be totally overrepresented with a probabilty of 1/6 while 2 and 12 have only a probability of 1/36.