An artist's depiction of an Extended Unit Death
Cynical? You're literally wrong. Looking up a example literally cannot stop someone from asking "are there any other possible solutions." If they don't ask this or want to start a new discussion, they were never that interested to begin with and were solely interested in having something that works.
First off, this is all speculation, so your liberal use of "literally" is misplaced. Secondly, getting an answer means there's no need to approach the community, which is perfectly fine, except that you're retrieving the answer through unethical means, and the next person with a similar problem will be faced with the same scenario.
Perhaps you don't think it's a matter of ethics, so let me give a quick analogy. If you're trying to set up a home theater system in your house and can't figure it out, it's not okay to lockpick your way into the neighbor's house to see how their system is set up. Sure, the neighbors only have a lock on their door to prevent thieves, so you could justify that since you aren't stealing anything, it should be perfectly fine. But it's not.
Could you please clarify what you're arguing here, exactly? Is it because an answer can't be readily found without starting a discussion, subverting a mapmaker's efforts to protect their map is acceptable? That may be your personal stance, and it was the stance of the Open Source Movement back in the day (which is why the subject of unprotectors is always a heated debate), but SEN's official policy is to respect the protection (or lack thereof) of maps for mapmakers (as Corbo highlighted above).
As a side note: unprotectors came in a wave against knowledge-hoarding. There was a time where people would figure out how to do certain things, and for whatever reason, they wanted to keep it a secret. Disabling stacked Dark Templar is one I distinctly remember. In any case, SEN has chosen the path against unprotectors, and in order to make unprotectors obsolete, we need to have solid documentation on all major mapmaking techniques. On a community level, point #4 is a problem, as avoiding a discussion will perpetually limit the community's public knowledge on mapmaking.
No, I'm not saying anything about "finding alternate solutions" or "ability to find new solutions." I'm talking about "not everyone cares about finding every (best) solution for every problem." Ergo, it's not a problem to look at an example if one simply wants a working solution.
Yes, not everyone cares about respecting the choice of the mapmaker to protect their map, and there's nothing we can do about that. However, the list I made is to illustrate the problems of this approach, and how much someone cares about these problems is subjective. Having an inferior solution is a detrimental possibility, even if any solution can be considered sufficient.
Neither of the above two points are helped by people telling others to "just use the search feature, this problem has been solved before". This sort of attitude pretty pervasive and directly inhibits people's motivation to open discussions on existing solutions.
This is a fair point, and it very well may be directly correlated to my observations of a lack of these sorts of discussions for point #4. In fact, the most I've seen new ideas emerge is when someone doesn't search for the solution and just posts an assistance topic, and members of the community come up with their own solution before someone points out that there is a documented solution already in place (a popular example of this is when someone asks how to uniquely track units).
So yes, you are absolutely correct on this, and I don't have an answer on how to improve this aspect of the community.
I wasn't talking about JCarrill0 specifically. You listed your point as a "problem," I'm simply pointing out that it isn't [logical, relevant].
My mistake for assuming you were referring to this scenario specifically. Indeed, I posted generalized issues as I see them, both on an individual and community basis.
