We aren't looking to add IL leaderboards to src, we'd rather not split the IL leaderboards. If anything, you might have more luck trying to rally another conversation for whether emulator should be allowed on FZC, which tends to come up again every 1-2 years without a definitive conclusion or much action being taken. You're better off looking to have that discussion in the FZN discord rather than here though.

I do agree FZC is a bit buggy; it was subject to a cyberattack a couple years ago and adjustments made to the site to fix the vulnerabilities left it in a less-than-ideal state unfortunately. I'm not involved with site development though, so I don't have much for specifics.

Being willing to make minor/insignificant accommodations to maintain a more robust leaderboard is significantly different than not putting care into it, but given the very low participation on the leaderboards I think it shows for itself that there's not much community interest. If you're arguing that there aren't enough runs and so we should just nuke the whole leaderboard then I suppose we could have that conversation, but I don't think that's what you're trying to say.

At this time I just see no reason to unnecessarily constrict an already scarce leaderboard for the sake of completely undemonstrated competitive integrity issues; like I said if it becomes a problem I'd be happy to revisit the conversation.

given the casualness of the RTA leaderboards and lack of tight competition I'm very much inclined to not care about the load time differences; RTA GX runs can basically be seen as miscellaneous runs compared to the actual IL competition, so personally I'm heavily in favor of continuing to allow emu. If it ends up being a problem in the future where 2 players set close competitive times and 1 of them is on emu making it faster IGT with slower RTA, then I'd be happy to revisit the topic, but given that the vast majority of the game time (while racing) runs at matching play speeds since console produces extremely minimal lag, I don't see this ever ending up an issue

Also I threw together little comparison videos of the JP-only scooter strats on check knight (the underwater rail section and the ending mega-boost part) and colda (the hillside part where you boost and slide down the whole way) as some things you could include that are probably pretty important, you could reuse my video or you could record it yourself, idk

check knight:

colda:

For the nebula zips, from what I could determine by recording zips on US and JP and counting frames, the zips lasted about the same amount of time (counting frames starting from when kirby flashes as the spin starts, to when speed starts to diminish at the end of the zip) in both US and JP.

On US, the zips that I had lasted 30, 32, 30, and 32 recorded frames, recording at 30fps. This equates to an average of 31 recorded frames, or 62 in-game frames.

On JP, the zips that I had lasted 28, 32, 30, and 34 recorded frames, which also averages to 31 recorded frames, or 62 in-game frames.

To measure the send-off period, i counted how many frames it took to drop all the way to 0 mph or 0 km/h while continuing to down A and holding right into the wall. It seemed to be there was about an extra recorded frame to slow down all the way, which makes sense with what we know about JP machines being lighter.

On US, the same zips from earlier took 13, 13, 13, and 14 recorded frames to stop, averaging to 26.5 in-game frames of a send-off window.

On JP, the same zips from earlier took 14, 14, 14, and 13 recorded frames to stop, averaging to 27.5 in-game frames of a send-off window.

Since JP machines take longer to slow down while charging since they're lighter, it seems that the scooter takes about another frame or so on average to stop after a zip, leaving you with a larger window to get a good send-off.

I hadn't really done scoot nebula on US whereas I have been practicing on JP, but from just playing a bit while testing these, the send-off window felt about the same to me, but you said it seemed easier on JP and just 1 extra frame could definitely help. Maybe a larger sample size could determine this better but spindash quality is a bit subjective, leading to possible variance in slow-down time based on the speed of the zip, and also, to get a more accurate number I would have to record in 60fps which would be awful to count frames with since I couldnt figure out the dolphin TAS recording tools.

For reference, the video of my zips (disregard the music playing in the JP section, i didnt pause music)