Not taking an argument is one thing, failing to reboot with an error message would then be fine.
A completely different thing is showing unexpected behavior, by shutting everything down and leaving an open root console.
This is the current manual page in trusty:
----
SYNOPSIS
reboot [OPTION]... [REBOOTCOMMAND]
halt [OPTION]...
poweroff [OPTION]...
DESCRIPTION
These programs allow a system administrator to reboot, halt or poweroff the system.
When called with --force or when in runlevel 0 or 6, this tool invokes the reboot(2) system call
itself (with REBOOTCOMMAND argument passed) and directly reboots the system. Otherwise this simply
invokes the shutdown(8) tool with the appropriate arguments without passing REBOOTCOMMAND argument.
Before invoking reboot(2), a shutdown time record is first written to /var/log/wtmp
----
It says that it will simply invoke shutdown *without passing REBOOTCOMMAND*. If the command actually did that, then this bug wouldn't exist.
Not taking an argument is one thing, failing to reboot with an error message would then be fine.
A completely different thing is showing unexpected behavior, by shutting everything down and leaving an open root console.
This is the current manual page in trusty:
----
SYNOPSIS
reboot [OPTION]... [REBOOTCOMMAND]
halt [OPTION]...
poweroff [OPTION]...
DESCRIPTION
These programs allow a system administrator to reboot, halt or poweroff the system.
When called with --force or when in runlevel 0 or 6, this tool invokes the reboot(2) system call
itself (with REBOOTCOMMAND argument passed) and directly reboots the system. Otherwise this simply
invokes the shutdown(8) tool with the appropriate arguments without passing REBOOTCOMMAND argument.
Before invoking reboot(2), a shutdown time record is first written to /var/log/wtmp
----
It says that it will simply invoke shutdown *without passing REBOOTCOMMAND*. If the command actually did that, then this bug wouldn't exist.
So, yes, it IS a bug.