I could save some time there, calculating only what has to be calculated, C-02 or C-03, but...
If it is stupid, why people sent funds to all 3, compressed-02, compressed-03 and uncompressed-04 addresses of the same private key?, by error? just for testing? who knows...
I discovered this by accident, because did not understand which is the check on the private key, to decide which Compressed-02 or compressed-03 Id I must use, so I did both, and also the other U-4, C-6 and C7 and calculated everything else up to the ripemd160 hash, and searched all 5 in my list of list 53M ripemd160 hashes with balance. Just in case there is a treasure somewhere.
You are confusing a lot of things.
Private Key is a scalar value.
Public Key is an EC point (X, Y) and Y has a parity (e.g. least significant bit odd or even, 1 or 0).
Y is a function of X.
So a public key can be uncompressed (04) in full (X, Y) form or compressed with just X and the Y parity (02 or 03 byte hint prefix)
If you are doing blind searches in hope of a collision, and you have a private key interval, you need to use the correct Y parity to produce the hashed address, otherwise you are hashing the address for private key
N - k which is always outside your private key search interval (for all intervals lower than N/2 in size, which is ~ 2^255), and the Y value is negated, hence the key for (X, -Y) = (X, P - Y). -Y = P- Y is always odd if Y is even, and viceversa, because P is odd.
If you are doing blind searches in hope of a collision and you don't have a private key interval in mind (so full-blown 256-bit keyspace), then your goal is to produce as fast as possible public keys, in which case you can use symmetry (02 / 03) and the 3-cycle endomorphism k*lambda^i -> (X*beta^i, ±Y) to quickly compute 6 (2 * 3) private keys and their points (public keys) for every generated private key. So it ends up as an optimization problem to do as fast as possible key generation with lowest amount of multiplications involved, since it was explained earlier that multiplication is the highest overhead of any possible group operation (since it's basically just rounds of additions).
The only number I am aware of that is larger than the number of all possible Bitcoin addresses is the number of electrons in the Universe (around 2-3 electrons for every possible BTC address).