Dolgy, "can you write a script" was the request. You clearly didn't notice.
Your version with checks is extremely inefficient in terms of execution time. It results in a constant cycle running throughout the game, with another N iterations per tick. At the same time, you need to strictly track the number of mines and number each one. Yes, such a script might be easier for a beginner than tables (by the way, they are still two-dimensional, in Jewill's version), but then the user will end up solving everything in a brute-force manner and will hit a dead end in more complex situations.
Moreover, the automatic reset of the mine's owner will trigger... immediately after it is captured! Unless the player manages to quickly click on the mine and assign the desired garrison (and it's not easy to carry it around)... Plus, the computer will lose the ability to control these mines at all.
So, despite all due respect for your experience with Multiplayer, which still delights the eye, the script you proposed in its current form is simply not working.
Jewill, I can't definitively say whether they can cause crashes, but I haven't encountered such a problem myself, just like Dolgy.
P.S. Since we're talking about advice, I recommend looking at how talkboxes are structured in the "Path of the Hero" map (in the talkbox.lia scripts) or in MCCS
If you haven't encountered any issues, I might be tempted to use talkboxes. If I disappear, it means they are corrupting saves and I need to rewrite 1000+ lines

Which I really don't want to do...
P.S.
And now, I'll continue my fascinating song "1000 and 1 questions to Hottabych and Co. about the fun dance of scripts in Heroes":
Attention, question (let's say - for thought). There is a function called CanShowPlayer(), or something similar, it is undocumented, but it checks the possibility of showing a message window to the player.
My tests have shown that the function works strangely, that is, it does not always give a clearly expected result. However, it seems that when standard modal (and not so modal) windows, such as garrison, level-up, etc., are open, it returns nil, and after the window is closed, it returns not nil. Do you think that, in combination with triggers on touching any object and a stream that checks for the player's ability to show the window, it is possible to create a trigger to close the window? That is, in the example of the script discussed above, to catch the moment when the player interacts with an object, then record x1 - the moment when showing the window became impossible (and we take the beginning of the stream in segments as the starting point), then x2 - the moment when showing the window became possible again. And accordingly, at this moment x2, we consider that the trigger has been activated - we give an event. In the case of our own window, we can also send a "signal" to this stream in the form of a name, for example, so that it performs a specific action.
It's a bit of a mess, but I'm somehow not at peace with these mines...
P.S. P.S.
All this song is only because, as far as I understand from the documentation, it is not possible to pass arguments through the standard callback parameter for windows (I will be happy if I am wrong again). And so, it would be possible to pass my own, which would eliminate the use of criminal arrays-buffers of data.
Будь яростней пред ночью всех ночей,
Не дай погаснуть свету своему!
Хоть мудрый знает – не осилишь тьму
Во мгле словами не зажжёшь лучей –
Не уходи безропотно во тьму.
