Estimate for V3 onion services uses network fractions for V2

I think the current estimate for the number of unique V3 onion addresses still uses the Network Fractions for V2. The structure of the hidden service directory changed between version 2 and 3. V2 used the fingerprint to determine the descriptors the relay is responsible for, while V3 uses a hash of the ed25519 fingerprint, the current shared-random-value and the current time period like this:

           hsdir_index(node) = H("node-idx" | node_identity |
                                 shared_random_value |
                                 INT_8(period_num) |
                                 INT_8(period_length) )

Since the string "node-idx" never occurs within the source code of this project, I'm fairly certain that the correct network fractions for version 3 are never calculated.

More importantly, the hsdir_spread was changed from 3 to 4 for V3 onion services. There is a comment in ComputedNetworkFractions.java:48 that says that the fraction should be divided by 8 instead of 3 (not sure why 8, I would have divided it by 4) but as far as I can see, this never happens. Every follow up calculation uses the same network fraction that was divided by 3 (See Parser.java:433).

Could someone with a better understanding of the source code please double check my analysis and confirm that this is indeed an issue?

Disclaimer: I'm not a Tor developer, just a researcher who looked into Tor onion services previously (I wrote an entry on the Tor Blog about a preliminary estimate on unique V3 onion addresses. I noticed that my estimate was too far off from the official one by Tor Metrics, so I tried to figure out what was wrong. Turns out that my calculation was wrong in a different way but while trying to reproduce the official numbers, I stumbled across this issue.