The cores should probably have stable releases, instead of downloading the latest builds that may or may not be broken. I know RetroArch gets around this a bit by allow backups, but it really shouldn't be necessary. I personally think that's a better idea than this repo's idea of pointing to stable commits (which hasn't been updated since 2017; I find it hard to believe that neither Snes9x nor mGBA have had stable commits since then).
Besides, the Netplay docs indicate (or at least used to; I can no longer find it) that you need to use the same version of a core (and I have had experiences where I've tried to join a game and received the message that I don't have a suitable core, when the only difference is the version (e.g. trying to use Snes9x 1.61 to play with someone using Snes9x 1.60)).
It's kind of odd that the two cores linked in this project are ones that have versioned upstream cores. Probably all cores should be versioned when stable. This is probably easiest for cores with upstream versioned cores. For example, upon the release of the recent Snes9x 1.61, the libretro fork should probably have been tagged 1.61 (or at least once stability has been reached).
One core that really strikes me as odd is FCEUmm which doesn't include a version at all, but only "(SVN)", though the SVN code on SourceForge was abandoned in 2016, when it (and other FCE forks) work merged into FCEUX (from which the FCEUmm core gets occasional backports). The source code indicates a version of 0.98.13, but so much has changed that that should probably be bumped (0.98.14, 0.99.0, or 1.0); older versions included the version 98.13mm (though, the actual version is 0.98.13). For cores like that, it should be up to the primary maintainers (in the case of FCEUmm, negativeExponent and NRS-NewRisingSun, if you can get the two of them to agree on anything), who would relay when it's time to tag a new version.
Another one is Picodive, which is nominally forked from the notaz/picodrive repo but seems to receive regular merges from irixxxx/picodrive, which is far more active than the notaz repo. That's all fine, but the libretro fork should tag new versions when the irixxxx repo does.
The cores should probably have stable releases, instead of downloading the latest builds that may or may not be broken. I know RetroArch gets around this a bit by allow backups, but it really shouldn't be necessary. I personally think that's a better idea than this repo's idea of pointing to stable commits (which hasn't been updated since 2017; I find it hard to believe that neither Snes9x nor mGBA have had stable commits since then).
Besides, the Netplay docs indicate (or at least used to; I can no longer find it) that you need to use the same version of a core (and I have had experiences where I've tried to join a game and received the message that I don't have a suitable core, when the only difference is the version (e.g. trying to use Snes9x 1.61 to play with someone using Snes9x 1.60)).
It's kind of odd that the two cores linked in this project are ones that have versioned upstream cores. Probably all cores should be versioned when stable. This is probably easiest for cores with upstream versioned cores. For example, upon the release of the recent Snes9x 1.61, the libretro fork should probably have been tagged 1.61 (or at least once stability has been reached).
One core that really strikes me as odd is FCEUmm which doesn't include a version at all, but only "(SVN)", though the SVN code on SourceForge was abandoned in 2016, when it (and other FCE forks) work merged into FCEUX (from which the FCEUmm core gets occasional backports). The source code indicates a version of 0.98.13, but so much has changed that that should probably be bumped (0.98.14, 0.99.0, or 1.0); older versions included the version 98.13mm (though, the actual version is 0.98.13). For cores like that, it should be up to the primary maintainers (in the case of FCEUmm, negativeExponent and NRS-NewRisingSun, if you can get the two of them to agree on anything), who would relay when it's time to tag a new version.
Another one is Picodive, which is nominally forked from the notaz/picodrive repo but seems to receive regular merges from irixxxx/picodrive, which is far more active than the notaz repo. That's all fine, but the libretro fork should tag new versions when the irixxxx repo does.