Because there is no alternate file you're actually just running plain ol'
:bd, deleting the current buffer...try it without
# and you'll see the result is the same. A similar thing happens with
:sbuffer and at least a couple other commands that accept
# as an argument: they silently behave as if no arguments were passed.
Along the same lines, if you try
:bunload # you get this error:
E90: Cannot unload last buffer. Run
:bunload with no arguments and, once again, you'll get the same result.
So we have evidence that
# is being replaced by "nothing" (probably an empty string). Where do we go from here? I poked around the help files for a while trying to find mention of this behavior. There was nothing explicit but
:h cmdline-lines says (scroll down a page or two) ...
When the character '%' or '#' is used where a file name is expected, they are expanded to the current and alternate file name.
I read that as Vim putting
# through the
expand() function (i.e.
expand('#')) or at least the same underlying code used there.
:h expand() says:
Expand .. special keywords. .. When using '%' or '#', and the current or alternate file name is not defined, an empty string is used.
Now none of the above is definitive or gives a clue as to Why? so I spent some more time digging...this time in the code. My C is very rusty and I don't have any good tools installed but I managed to find a function that does some setup for
do_bufdel(). This sends command line arguments through
buflist_findpat() which, if
# is encountered, returns value
curwin->w_alt_fnum. That's the "buffer number" of the alternate buffer...which can't be a positive value in our scenario. (There's no check for whether the alt file is valid/exists before that return value is selected.)
Back out in
do_bufdel() a check is made against that return value for a buffer number less than 0 in which case the parameter processing loop is broken out of. That would result in no parameters being presented to the core
:bdelete code...which is right in line with my earlier intuitions.
It appears to be working as designed in that I didn't see anything that looked like a clear bug. Possibly sin of omission, though...a corner case that has been overlooked and thus has no graceful handling. But only the developers that wrote this know for sure. So the final step would be to try to get their input. As Christian B. said asking on the vim-dev list is the way to go.
buflist_findpat() is a utility function so it wouldn't require a stretch of the imagination to assume that
:buffer, etc. are using it, too...that would explain their common behavior with respect to