If it does, it certainly doesn't say so in the documentation of print. This is the documentation of print (from 5.8.5):

       print FILEHANDLE LIST
       print LIST
       print   Prints a string or a list of strings.  Returns true if success-
               ful.  FILEHANDLE may be a scalar variable name, in which case
               the variable contains the name of or a reference to the file-
               handle, thus introducing one level of indirection.  (NOTE: If
               FILEHANDLE is a variable and the next token is a term, it may
               be misinterpreted as an operator unless you interpose a "+" or
               put parentheses around the arguments.)  If FILEHANDLE is omit-
               ted, prints by default to standard output (or to the last
               selected output channel--see "select").  If LIST is also omit-
               ted, prints $_ to the currently selected output channel.  To
               set the default output channel to something other than STDOUT
               use the select operation.  The current value of $, (if any) is
               printed between each LIST item.  The current value of "$\" (if
               any) is printed after the entire LIST has been printed.
               Because print takes a LIST, anything in the LIST is evaluated
               in list context, and any subroutine that you call will have one
               or more of its expressions evaluated in list context.  Also be
               careful not to follow the print keyword with a left parenthesis
               unless you want the corresponding right parenthesis to termi-
               nate the arguments to the print--interpose a "+" or put paren-
               theses around all the arguments.

               Note that if you're storing FILEHANDLES in an array or other
               expression, you will have to use a block returning its value
               instead:

                   print { $files[$i] } "stuff\n";
                   print { $OK ? STDOUT : STDERR } "stuff\n";

The only part that hints about ambiguaty is the part I boldfaced. But it doesn't explain at all why it parses the statement differently whether there's a space between the third and fourth token. Not that I expect most programmers to know what the phrase next token is a term means.