> Any chance of putting a check in translate.py so that if an either type is
> found an error will be signaled?

I already added this to the existing issue220. (Sorry, should have pointed this
out.)

> I suppose a more sophisticated alternative
> would be to emit a warning and simply rewrite any EITHER construct to OBJECT.

I'd prefer to just implement "either" properly, which shouldn't be much work --
once the community has come to a consensus what the proper semantics are. :-)

> Question:  is there any danger that the above rewrite could be incorrect?

Unfortunately yes, e.g. if the either type occurs in an action parameter binding
or universal quantifier binding. Think of something like

(forall (?b - (either red-bomb green-bomb)) (defused ?b))

in the context of

:types (red-bomb green-bomb blue-bomb - bomb)

where the above construct would not defuse blue bombs, but the rewrite would.

I'm reasonably sure that mixed types involving numbers and objects such as
(either airplane number) would not be legitimate. In the absence of a proper
spec, some people might of course disagree, but I think that there'll be little
disagreement here.

On issue297, Malte points out that 

We don't support "either" at all,  so any tasks that use them are bound to lead
to errors somewhere along the way.

Any chance of putting a check in translate.py so that if an either type is found 
an error will be signaled? I suppose a more sophisticated alternative would be 
to emit a warning and simply rewrite any EITHER construct to OBJECT.

Question:  is there any danger that the above rewrite could be incorrect?  Is 

(EITHER AIRPLANE NUMBER) 

legitimate?

If so, then perhaps just emitting an error would be best.