I would suggest that the general consensus is that you post them anywhere it makes sense to use, but overall I feel that there is a better way to structure everything in the solution to minimize problems, promote positive modularity and facilitate maintenance.
Well, yes, in the general case, you can just put everything anywhere. However, problems begin when you work as a team. As a team, other people need to understand the structure of the program in order to be able to efficiently create code. This implies consistency, which is the ultimate goal.
So this is not just a matter of intuition; In all the companies I worked on, I started by writing a coding standard and persistently applied it everywhere. In this coding standard, I usually put a ton of good / bad methods related to threads, static use, placing variables / classes, etc.
The link http://se.inf.ethz.ch/old/teaching/ss2007/251-0290-00/project/CSharpCodingStandards.pdf and https://msdn.microsoft.com/en-us/library/ff926074 will open . aspx will give you a start, although the first is a bit outdated and both do not answer your question. However, it can help with what you are trying to achieve in the end.
[...] I currently have delegates in their own file in the delegate namespace. Is there oversight when I am doing this, or am I abusing the use case for delegates - or is it due to current expectations of use?
A shared library with interfaces makes sense. An interface is essentially a contract between a “client” and a “server,” which is an important advantage for decoupling a piece of software.
At this point, you should understand that part of the interface is a functional decomposition, not a technical one. In other words: the fact that you need an interface library is a matter of contract, not technical designs. So I don’t understand why you ever put classes in the classes folder and why you put delegates in the delegates folder. In short, the "delegates" folder does not make any sense to me. Place the material where it belongs.
At this point you must make a decision. (1) You can put the delegate in one file, (2) you can put the delegate in the class file in which it was used (I usually use delegates for the same purpose), (3) you can do both depending on one / multitasking and (4) you can designate single-delegates nested in a class. This basically means that you consider the delegate as a description of a function pointer and do not see it as a real "class".
Looking at functional decomposition, you can argue that a pointer to a function belongs to a class, like methods.
So, to lure. Personally, I usually choose option (2) or (3), because it is short, understandable and concise, and does not affect the amount of "typing of work", like (4). Choosing (1) will probably inflate your application with small files that have little or no purpose, which will confuse other developers.