The behaviour you have described seems (in my opinion) to be more of an issue with dcc sizes of '0' being 'accepted' without even connecting to the user. If the filesize is 0 mIRC should ignore the request completely. Attempting to send non-existant files is not desirable, but the acceptance (and creation) of the dummy files is the real cause of the 'spam'. This could probably be used to cause grief with virus scanners that run checks on filenames.
I think the /dcc send behaviour could be improved:
- If the valid path points to a file, initiate the send.
- If only a valid directory name is given, open the find file dialog in that directory.
- If a valid directory and non-existant file is given, open the find file dialog in that directory.
- Otherwise produce a 'no such file' error.
At least this isn't a crashable DCC issue. :P
Edit: the send only seems to initiate with NUL, CON, COMn, LPTn (and PRN), <, >, ., and paths to folders (eg: C:\windows will attempt to send 'windows'), * changes the 'files of type' editbox, and in other cases produces the 'no such file' error. The 'not crashable' statement is now yet to be proven.

Edit2: More DOS device names, none of which have produced a crash (at least on XP). mIRC also blocks files with the device names on the receivers end.