Having dealt with thousands of bug reports over a period of years, I have come to have the approach I do because it is by far the most efficient way of resolving issues. I have eventually realised that a significant part of the process of dealing with bug reports is teaching people how to write useful bug reports, allowing the reported problem to be solved as quickly and effectively as possible. Lots of beginners print screen an error message and report it, and it is literally impossible to do anything about it. Another very common case is they carefully write up a list of steps, but don't share their .capx. I follow the steps (which can sometimes take a while, especially if there are vague bits which I get past by trying different combinations of interpretations) and it turns out they forgot a step which the original .capx they used did, and was the real cause of the problem. If I had the .capx, I could have solved it immediately. This kind of thing is not useful to anybody: it wastes developer time, and makes it take longer to get user's issues fixed. Unceremoniously closing the issue is the quickest way to get people to respect the guidelines, which helps everybody.
Everything in the bug report guidelines is from this kind of thing happening again and again and again and again and again, until I draw the line and say I will outright reject any reports that do not follow the given requirement. And it still keeps happening. Yes, I can see that if you are a new user, you come along and spend some time carefully writing up a list of steps but don't provide a .capx, and then your report is immediately closed, you might think I'm being cruel or something, but experience has taught me there is about a 50% chance I'm not going to see the problem. Given there are over 4000 bug reports and they still come in fast, this can turn in to months of wasted developer time which could be spent on something more useful like developing new features, and the reporter could take some simple steps to help us help you effectively.
The bug report guidelines are the things you need to do for a software developer to usefully and quickly investigate your problem, so please take them seriously.
Also if you buy Microsoft Visual C++, I don't think you'd expect Microsoft support to help you debug your C++ apps for free - although they (or someone else) might offer a paid service for that - but they would address reasonable bug reports. Similarly I don't think it's fair to expect us to solve the event problems in your projects. When it comes to bug reports, as I've mentioned large projects are not even useful. In general, the larger the project, the less likely it is to be a useful bug report. If you can't reproduce the problem in a new empty project, it is probably not a bug (another point with years of experience behind it). This makes the copyright/not-sharing-my-work issue irrelevant, because I don't want you to send me your whole project anyway. (With one sole exception: performance profiling - but most bug reports aren't about that.) This is also industry standard. I would not expect Microsoft to fix a C++ compiler bug by sending them the entire Construct 2 source. They would require that I reproduce the problem in a minimal program before they could investigate. Then I also don't need to send the C2 source code anywhere, and they can fix the problem more quickly.