I agree. The old behaviour (deleting duplicates and continuing) was a little 
unexpected, but now I think that it is just as valid as aborting in case 
duplicate variables are found. Let's leave things as they are :-)

I've left some code comments.

The fact that the change introduced several new bugs (wrong exit code, wrong
documentation) made me question the utility of this behaviour change somewhat.
I'm not against the change if implemented correctly, but I also don't think it
gains us anything. We are just replacing one set of behaviours with another one,
and apparently this isn't so easy to implement.

I'd be surprised if the genetic algorithm returned duplicate variables in a
pattern. If I recall correctly from the description of the algorithm, it
essentially encodes patterns as sets of variables (or as bit-strings where each
bit represents presence of absence of a given variable in a pattern). But I
never really looked at the code.

I don't mind making duplicate patterns illegal, but if we do, this has to be
documented in the user documentation.

Have you looked at the exit code 15 results in the experiment?

I made a pull request at https://bitbucket.org/jendrikseipp/downward/pull-requests/87 .

Revision issue772-v1 aborts with an error message if a pattern contains duplicate variables. 
We discussed offline that PDBs obtained with the genetic algorithm might contain duplicate 
variables, but the experiment below suggests that this is not the case:

http://ai.cs.unibas.ch/_tmp_files/seipp/issue772-v1-no-dominance-pruning.html

The pattern validation code in pdbs/validation.cc also prints a warning if a duplicate 
pattern has been found. Should I test whether we can also abort with an error message in that 
case?

If printing on stderr, we must also abort, since we consider output to stderr an
error. I think it makes sense to abort with INPUT_ERROR.

I'll do so during the next Fast Downward meeting.

I have no strong thoughts on this. Can you ask the others for their preferred
behaviour?

Currently, the planner allows duplicate variables in patterns both in debug and release mode:

./fast-downward.py --debug ../benchmarks/gripper/prob01.pddl --search "astar(cpdbs(manual_patterns([[0, 0]])))"
./fast-downward.py --debug ../benchmarks/gripper/prob01.pddl --search "astar(pdb(manual_pattern([0, 0])))"
./fast-downward.py ../benchmarks/gripper/prob01.pddl --search "astar(cpdbs(manual_patterns([[0, 0]])))"

All invocations remove the duplicate variable (in the ctor of PDB), print a warning to stdout and successfully find a 
plan. I think it would be better to abort with an input error in this case or at least print the warning to stderr.