Added the new issue299 for these simplification opportunities. Marking this one
as resolved since the remaining problems are already tracked in issue146. I've
added a cross-reference to this one there.

> I then get a third crash, which is the dreaded "add effect with uncertain del
> effect partner?". Am now looking into that.

Indeed this seems to be the well-known but tricky issue146 (also documented at
http://www.fast-downward.org/PddlSupport#Limitations).

I've added more debug output to make it clearer what is going on. The translator
chokes on this operator:

(transit_via_door bob bobs_office gregs_office door_0)
PRE: Atom pmode(m_free)
PRE: Atom in_room(bob, bobs_office)
PRE: Atom is_open(door_0)
PRE: NegatedAtom new-axiom@4(bob)
PRE: Atom trust(bob)
ADD:  -> Atom in_room(bob, gregs_office)
ADD: Atom in_room(bob, bobs_office), NegatedAtom new-axiom@6(bobs_office, bob,
bob) -> Atom trust(bob)
ADD: Atom in_room(adam, bobs_office), NegatedAtom new-axiom@6(bobs_office, adam,
bob) -> Atom trust(adam)
ADD: Atom in_room(greg, bobs_office), NegatedAtom new-axiom@6(bobs_office, greg,
bob) -> Atom trust(greg)
ADD:  -> Atom trust(bob)
ADD: NegatedAtom in_room(bob, gregs_office) -> Atom trust(bob)
ADD: NegatedAtom in_room(adam, gregs_office) -> Atom trust(bob)
ADD: NegatedAtom in_room(greg, gregs_office) -> Atom trust(bob)
DEL:  -> Atom in_room(bob, bobs_office)
DEL: Atom in_room(bob, gregs_office), Atom trust(bob) -> Atom trust(bob)
DEL: Atom in_room(adam, gregs_office), Atom trust(adam) -> Atom trust(adam)
DEL: Atom in_room(greg, gregs_office), Atom trust(greg) -> Atom trust(greg)
DEL: Atom in_room(bob, gregs_office) -> Atom trust(bob)
DEL: Atom in_room(adam, gregs_office) -> Atom trust(bob)
DEL: Atom in_room(greg, gregs_office) -> Atom trust(bob)
cost: 0

It doesn't like the fact that trust(bob) [or one of the other
trust(...) atoms?] is deleted and/or added within conditional effects
with incomparable conditions. At least for trust(bob), this is a bit
stupid since all these effects are redundant: the unconditional add
effect "ADD:  -> Atom trust(bob)" trumps all other effects on
trust(bob), and since that is already a precondition, even that add
effect is redundant. So in addition to our current limitations on
conditional effects setting different values of the same finite-domain
variable, there are also some huge missed simplification opportunities
here.

OK, that other crash is related to "(knows bob bob_pgp_pwd)" being present in
the initial state twice. I've now changed the crashing site to no longer worry
about things like this, but duplicates in :init should still be avoided since
they can cause other problems (e.g. mutex groups being needlessly rejected).
That part is related to issue294.

I then get a third crash, which is the dreaded "add effect with uncertain del
effect partner?". Am now looking into that.

We don't support "either" at all, so any tasks that use them are bound to lead
to errors somewhere along the way. So to rule out that this is the cause here,
I've replaced "(either ...)" with "object" everywhere, but the problem persists.

Your analysis looks good to me, and I think I fixed the problem (fix not yet
pushed) but then I get a crash somewhere else. Will look into this further.

Maybe because of the disjunction in the preconditions, the 
reachable_action_params seem to sometimes have action parameters, and sometimes 
the action parameters plus the existential parameters:

print [len(reachable_action_params[action.name][i]) for i in 
range(len(reachable_action_params[action.name]))]
print [len(reachable_action_params[action.name][i]) for i in 
range(len(reachable_action_params[action.name]))]
[6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 
6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 6, 6, 6, 
6, 6, 6, 6, 6, 6, 6, 6, 6, 8, 8, 6, 6, 6, 6, 6, 6, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 
8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 
8, 8, 8, 8, 8]

Possible additional wrinkle, related to recent correspondence on the mailing 
list:  The authorization predicate, referenced in this precondition, has an 
EITHER type argument:

   (authorization ?k - c_ekey ?a - (either c_info c_human))

I do not know that this is related, but thought it worth a mention.  No EITHER 
typing is used in the parameters or quantifiers of this action, though.

Minor correction:  it was not, strictly speaking, a conjunct --- I didn't read the 
preconditions carefully enough.  But it's a subexpression and should be easy to 
find.

[Adding malte manually, since it looks like the nosy list may be messed up...]

I have investigated further.  The crash happens processing action encrypt_file.

This has six parameters and the params argument to add_inequality_preconds seems 
right:

(Pdb) print params
print params
('nobody', 'y_iexplore', 'yeti', 'bob_uid', 'everyone', 'bob_pgp_key')

However, the action.parameters is of length 8:
 print action.parameters
print action.parameters
[<pddl.pddl_types.TypedObject object at 0x1005f5810>, 
<pddl.pddl_types.TypedObject object at 0x1005f3810>, 
<pddl.pddl_types.TypedObject object at 0x1005f6410>, 
<pddl.pddl_types.TypedObject object at 0x1005f6390>, 
<pddl.pddl_types.TypedObject object at 0x1005f6610>, 
<pddl.pddl_types.TypedObject object at 0x1005f65d0>, 
<pddl.pddl_types.TypedObject object at 0x1005f6a50>, 
<pddl.pddl_types.TypedObject object at 0x1005f6a90>]
(Pdb) print len(action.parameters)
print len(action.parameters)
8

The additional two parameters seem to be the quantified variables from the 
existentially quantified conjunct in this action's preconditions.

This makes me wonder if a problem could have been caused by the recent patch to 
handle nested existentials.

If there's anything else I can do to help track this down, please let me know.

Attempting to run one of the bams-gen problems, I get the following error:

Traceback (most recent call last):
  File "/Users/rpg/obtw/obtw-trunk/code/fastDownward/SIFT-example-
scripts/../src/translate/translate.py", line 568, in <module>
    sas_task = pddl_to_sas(task)
  File "/Users/rpg/obtw/obtw-trunk/code/fastDownward/SIFT-example-
scripts/../src/translate/translate.py", line 447, in pddl_to_sas
    partial_encoding=USE_PARTIAL_ENCODING)
  File "/Users/rpg/obtw/obtw-
trunk/code/fastDownward/src/translate/fact_groups.py", line 103, in 
compute_groups
    groups = invariant_finder.get_groups(task, reachable_action_params)
  File "/Users/rpg/obtw/obtw-
trunk/code/fastDownward/src/translate/invariant_finder.py", line 134, in 
get_groups
    invariants = list(find_invariants(task, reachable_action_params))
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/contextl
ib.py", line 34, in __exit__
    self.gen.throw(type, value, traceback)
  File "/Users/rpg/obtw/obtw-trunk/code/fastDownward/src/translate/timers.py", 
line 32, in timing
    yield
  File "/Users/rpg/obtw/obtw-
trunk/code/fastDownward/src/translate/invariant_finder.py", line 134, in 
get_groups
    invariants = list(find_invariants(task, reachable_action_params))
  File "/Users/rpg/obtw/obtw-
trunk/code/fastDownward/src/translate/invariant_finder.py", line 95, in 
find_invariants
    balance_checker = BalanceChecker(task, reachable_action_params)
  File "/Users/rpg/obtw/obtw-
trunk/code/fastDownward/src/translate/invariant_finder.py", line 18, in __init__
    action = self.add_inequality_preconds(act, reachable_action_params)
  File "/Users/rpg/obtw/obtw-
trunk/code/fastDownward/src/translate/invariant_finder.py", line 52, in 
add_inequality_preconds
    if params[pos1] == params[pos2]:
IndexError: tuple index out of range

Attaching input files.