Yes. But be aware that by "region" I am referring to JASS region. GUI has no wrapper for this type.
The GUI type called "region" is actually a JASS "rect". Rects do not suffer this problem as they define an abstract area of the map.
The GUI event "A unit enters..." internally creates a region containing cells which make up an approximation of the passed in rect.
Thanks for clarifying.
The engine will not make mistakes as it is being run on a computer. Yes it can make mistakes but statistically the chance is insignificant as otherwise computers would be crashing all the time.
The engine can be buggy at times which is likely what you are mentioning. That said as long as you do not run into these bugs you are free to push the limits to whatever is reasonable. For example Warcraft III will (should...) not crash when 4,000 units are attacking each other at the same time, but it might perform so badly the map is as good as unplayable. It will still function correctly and the end results will still be what can be estimated, however the performance until the results are met are not a usable experience.
What I mean more specifically, is that my experience is that the game will fail to perform smoothly unless it has a failsafe system supporting it, especially when it comes to timing and synchronisation of game events. The poor accuracy of "wait" is a great example of this, but I think it applies to just about anything that relies on assumed chronological execution. I could, in theory, expect events A, B, and C to trigger in that order, based on disconnected events that "should" allign just right, but in distrust of how the game handles delicate timing, I'd much rather ensure this order, by running these triggers through a separate execution trigger, to ensure that the order ends up being exactly as intended. I think it's good practice to not base your designs around underlying architecture in general, as it becomes far more vulnerable that way. Some of the recent patches would be a decent example of this, as they broke a lot of old maps relying on the underlying game handling their game mechanic logic, rather than defining it themselves. I also tend to avoid needlessly burdening the system with pointless trigger executions. Fast periodic events is something I moderate very harshly, for example. It's often much better to simply run these things manually, not just because it's smoother, but because it can be a very bad habit to leave a hundred periodic events firing at all times for no particular reason. I also take issue with performing very large tasks during gameplay, as the game can't load balance it due to gameplay chronology, so I think it's important to keep load balancing in mind as well.
All of these are examples of what I mean, when I say that I recommend not leaving the tedious details for the game engine to handle, as it will often either fail to do so, or perform very badly because of it. Not designing a map to have 4000 units engaged in combat is an example of this, albeit a fairly obvious one.
This may be excessively conservative for Warcraft 3 at the moment, with how powerful the average PC is compared to what was expected to run the game originally, but I have a feeling that performance optimisation is going to play a much bigger role in Reforged, so I like to keep that in mind.
If one wants to reduce the trigger count and improve trigger script efficiency then I recommend learning Lua or JASS. One can perform a lot of optimizations and scripting practices with those that can reduce the resulting script bloat dramatically. Simple things like bundling multiple actions into a function instead of copying them hundreds of times can potentially save thousands of lines of script and make modification to those actions take a couple of seconds instead of hours.
I generally don't like using JASS in the editor. I don't find the syntax to be very well thought through. For example, it'd make a lot more sense if every object that needs to be cleared from the memory, had a function attached to a class, rather than every single type of object having a separate function... like... instead of "Call RemoveLocation(udg_location)", why not just use "udg_location.remove()" That way, you wouldn't have to look up the exact format for every single object type that you are cleaning up. Granted, I don't know much about how JASS works, I just use it whenever nothing GUI is available...
As for functions, I kinda just do those with triggers. You can use variables for arguments and return values, and then just run the trigger as you would a function. I think you can refactor code just fine in the GUI this way. Hell, most of the time, all you need is just a bit of a dynamic design, instead of one that declares 100 different scenarios explicitly. Granted, it's a bit clunkier to write "functions" in GUI than JASS, but you have the advantage of it being 100% GUI, which is just easier to work with, unless you've actually bothered memorizing the majority of the JASS syntax, which is a point that I'd wager takes a good year of coding to really get to. I personally find GUI to be easier to maintain, and it's a lot easier to hand someone GUI based code, than JASS. The deep layered actions can be a pain in the ass, sure, but I tend to just assign that stuff to a variable instead, so I don't have to redo the whole thing when I make a change at a higher layer of dropdown items.