The integration into the respawn system is the most planning-intensive. How the first spawn and the following respawns of players should work can vary a lot per game mode, which is why the framework currently does not offer one all-in-one solution. For now, only one respawn system "template" exists that is meant for a single character with a single default loadout prefab and no faction association. A similar multi-character setup can be found in one of the open-source projects using this framework EveronLife:Spawning.
A tighter integreation into the existing respawn system will be added in an upcoming feature update.
The built in EPF_BasicRespawnSystemComponent can be used for simple game modes where each player has one character. The method flow is designed to be modular so custom logic can be added in between the spawning process. Depending on your needs consider inheriting from EPF_BaseRespawnSystemComponent to build your own customized basic respawn system. The respawn system component needs to be attached to your game mode entity.
It is important to wait for the persistence manager to have completed the setup or else characters spawned too early can count as baked which will cause problems. Subscribe to the EPF_PersistenceManager.GetOnActiveEvent() event to await this.
By default the Self Spawn option in Character_Base.et is disabled. This is so that normal player characters do not automatically spawn even if their controlling person is not connected to the server. To still get dead bodies to spawn the example respawn system above uses the intended method for this which is to catch the OnPlayerKilled event and force spawn the dead body for the next restart. The garbage manager lifetime persistence info will take care of removing it again after the restart once the configured decay is reached.
Alternatively, it is of course possible to just override the prefab in a game mode mod, enable Self Spawn for everybody again and have all the characters spawn back if that is what the gameplay desires. That allows players to kill others who still need to connect. In this case on player reconnect instead of attempting to spawn the joined players character again - because it is already spawned - use EPF_PersistenceManager.FindEntityByPersistentId() to get the IEntity that belongs to the player and hand out from the respawn system. If the character was killed a replacement was maybe already spawned with the new id, depending on how the system is implemented, otherwise, that needs to be taken care of then.
One design aspect to keep in mind is how to handle persistent ids. For convenience, it might make sense to keep the same id for the real player so that associated data in the DB is not tied to the dead body (e.g. level info, logs, playtime statistics, etc). Either the Bohemia UID is put onto the character or a generated id is transferred over to the new body each time. This is how its done in the example respawn system on these lines.