I think that behavior is true of AGK's return indexes in general, but I'm not sure what will happen on the multiplayer side of things once a limit is reached. Hopefully it would loop or something. You could probably set up a test project to just cycle through big chunks of connect/disconnect events to gauge how high the limit is and what happens. If there is a potential problem, you could set up some kind of server-side restart/relaunch (automatic or manual) to refresh them and start over at a desired interval.
This forced balloon structure can be a bit challenging for designing a multiplayer system around in general, especially considering how some things are 'freed' upon release while others aren't. Plus, listing can be mismatched also. For example, you can access a player list in AppGameKit via the 'GetNetworkFirstClient' and 'GetNetworkNextClient' commands. However, the list of players will not be consistent between host and clients. Nor will the list be consistent with the sequence of client indexes/joining order. In fact, if you poll the player names with 'GetNetworkClientName', you'll find that your name will generally be in the first client slot returned from the list, regardless of the index it may have been assigned and regardless of whether you were the host or a client. So not only are indexes not persistent or consistent, the returned player list isn't either. And the player list itself won't match the index order or join order either.
So hopefully, you've also accounted for the potential mismatches and differences between the various client values so each can handle their own listing structure independently yet still remain linked for required dependencies. It's all quite a departure from how multiplayer frameworks typically handle things.