Bug in ech?

We came across some strange behavior of ech.  Is this a bug or
are we missing something?  Thanks for your help,

	Jacco

This is our narrowed down chr file, "tr":

  handler tr.

  :-lib(fd).

  constraints tr/3.

  % cleaning rules
  tr('b','b','b') <=> true.

  % propagation rules
  tr('b','b',X) ==> X #= b.

Sample session using ech:
ECLiPSe Constraint Logic Programming System [kernel]
Copyright Imperial College London and ICL
Certain libraries copyright Parc Technologies Ltd
GMP library copyright Free Software Foundation
Version 5.2 #10, Tue Jun 26 02:14 2001
[eclipse 1]: lib(ech),compile('tr.chr').
lists.pl   compiled traceable 5188 bytes in 0.02 seconds
strings.pl compiled traceable 0 bytes in 0.01 seconds
numbervars.pl compiled traceable 764 bytes in 0.01 seconds
ech2pl.pl  compiled traceable 77044 bytes in 0.03 seconds
ech.pl     compiled traceable 32688 bytes in 0.10 seconds
WARNING: Hiding imported predicate handler/1 from module ech in module eclipse (use local/1)
fd_domain.eco loaded traceable 0 bytes in 0.02 seconds
fd_arith.eco loaded traceable 0 bytes in 0.07 seconds
fd_util.pl compiled traceable 2128 bytes in 0.01 seconds
fd_chip.pl compiled traceable 4720 bytes in 0.03 seconds
fd_elipsys.pl compiled traceable 11036 bytes in 0.02 seconds
fd.eco     loaded traceable 0 bytes in 0.13 seconds
Found CHR tr/3, generating transformed code
tr.chr     compiled traceable 28 bytes in 0.13 seconds

Yes (0.25s cpu)
[eclipse 2]: X::['e','b'],tr(b,b,X).

No (0.00s cpu)
[eclipse 3]: 

Here I expected 'Yes', with X=b.

Strange enough, when I run this through Eclipse 5.11 with the
old chr library, it works OK:

ECLiPSe Constraint Logic Programming System [kernel]
Copyright Imperial College London and ICL
Certain libraries copyright Parc Technologies Ltd
GMP library copyright Free Software Foundation
Version 5.1.1, Thu Feb 22 01:08 2001
[eclipse 1]: lib(chr),chr2pl('tr'),[tr].    
strings.pl compiled traceable 0 bytes in 0.01 seconds
chr2pl.eco compiled traceable 0 bytes in 0.03 seconds
chr.eco    compiled traceable 0 bytes in 0.04 seconds
lists.pl   compiled traceable 5188 bytes in 0.01 seconds
tr.chr     compiled traceable 1686 bytes in 0.02 seconds
fd_domain.eco compiled traceable 0 bytes in 0.01 seconds
fd_arith.eco compiled traceable 0 bytes in 0.05 seconds
fd_util.pl compiled traceable 2052 bytes in 0.01 seconds
fd_chip.pl compiled traceable 4644 bytes in 0.02 seconds
fd_elipsys.pl compiled traceable 10564 bytes in 0.01 seconds
fd.eco     compiled traceable 0 bytes in 0.10 seconds
tr.pl      compiled traceable 2284 bytes in 0.10 seconds

yes.
[eclipse 2]: X::['e','b'],tr(b,b,X).

X = b
yes.

What is going on here?  When I remove the clean up rule,
ech gives me X=b, but with a delayed rule tr(b,b,b), which is
not what I want:

[eclipse 3]: X::['e','b'],tr(b,b,X).

X = b


Delayed goals:
        tr(b, b, b)
Yes (0.00s cpu)


Any help would be appreciated,

Jacco