My understanding is that this bug has been fixed with the new option parser. Closing.

The option parser is currently very bad at error handling in general. Without
having looked at this precise issue in detail, I would recommend against trying
to patch the many holes in the error handling individually, hole by hole.

Instead, I think this is one of the cases where a complete reimplementation of
the text-handling side of things would be good, using a more principled parsing
approach based on tokenization and constructing syntax trees based on a formal
grammar. This is not particularly difficult, and I am happy to advise, but also
I think this is low priority.

No astar(max([ff()], cea())) does not produce an error and silently swallows the
additional argument.

From the issue title it sounds like the problem was that the parser doesn't
complain if there are unused options left over at the end of parsing. As far as
I know we only fixed the parsing of lists to require explicit brackets around them.

So for example, would the following option also produce an error?
  astar(max([ff()], cea()))

With the current master branch this is no longer true. If we run the following
command with missing brackets around the list, there will be a parse error.

command:
./fast-downward.py ../benchmarks/blocks/probBLOCKS-4-0.pddl --search
"astar(max(ff(), cea()))"


parse error:                                   
expected list at:                              
ff                                             
Usage error occurred.

In the following call (which is missing the brackets around the list), the ff
heuristic is parsed as a positional argument and interpreted as a list of length
1. The additional argument "cea()" is ignored without warning.

./fast-downward.py ../benchmarks/blocks/probBLOCKS-4-0.pddl --search
"astar(max(ff(), cea()))"

This is related to issue507 but not quite the same (see msg6164).