I consider this game to be more of a sequel than a spin-off, though mechanically it won't change a lot. So Don't Starve is a very appropriate example.
The reason why it is a separate game, and why Don't Starve Together is a separate game, is that multiplayer is a completely different beast and unless a game is coded to eventually have multiplayer from the beginning, "adding multiplayer" is rarely a thing. Because now instead of "you click this defeated Automon to add it to your party", it's more like "you click this Automon to tell the server that you would like to capture this Automon to your party, the server tells you if you're allowed to do that and updates the game state accordingly, then tells the client what his new party is". The game objects themselves have no agency or permanence, and the battles are just replays of the story that the server told you.
Also, I want to redo the visuals and change some mechanical aspects of the game, like areas and how legendaries show up, but didn't want those changes in the original game.
I think I know what happens with the reject/capture bug you saw, the server probably checks if the party is full and refuses to act, before it checks if the request is actually a rejection. Will look into it.
Your game seems turn based, if you are early enough in development then it's probably not too late to look into multiplayer development. The way I structured the multiplayer system is probably not even optimal, so you might figure out a way to do it without even going beyond Game Maker - the reason I didn't bother is that I think GM is only peer to peer, and I'm not sure if there's a way to prevent cheating from the host client if you do that (by modifying data in memory through Cheat Engine or something).
If it's your first game, I wouldn't bother though, you'll spend a lot of time coding the network code instead of actually making a game