It’s a tradeoff, it’s making it much easier for me to manage actual code changes. These are technically 2 different solutions, so they need 2 different places on the roadmap to evaluate and track, or in this case: reject.
Regardless, thanks for your explanation. 
This is helpful.
Regarding the unwanted removals, this is solved by an additional check that the player must also be marked inactive. This gives the confirmation you describe, as the script can’t do anything until the leader marks a player as eligible for deletion. This change has made it into the other feature’s thread.
As far as I can tell, that solves the problem entirely in a way that doesn’t need a literal manual checkin as described in this thread here.