Bug in suspend (or fd)

Not sure who to "blame" for this one:

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.0, Wed Feb 28 01:09 2001
[eclipse 1]: lib(fd).
fd_domain.eco compiled traceable 0 bytes in 0.02 seconds
fd_arith.eco compiled traceable 0 bytes in 0.05 seconds
fd_util.pl compiled traceable 2120 bytes in 0.01 seconds
fd_chip.pl compiled traceable 4712 bytes in 0.02 seconds
fd_elipsys.pl compiled traceable 11028 bytes in 0.02 seconds
fd.eco     compiled traceable 0 bytes in 0.10 seconds

yes.
[eclipse 2]: suspend(writeln(foo), 1, [X->inst]), printf("%Mw.%n", X).
X{suspend : suspend(['SUSP-_262-susp'|_275] - _275, [], []), fd : _280}.

X = X

Delayed goals:
        writeln(foo)
yes.
[eclipse 3]: 


Note that the call to suspend has given X an "fd" attribute (left
unbound) (same thing happens for other solvers).  Is this intentional? 
If not, is it supposed to be harmless?  Because it isn't, at least in
the case of fd:

[eclipse 3]: suspend(writeln(foo), 1, [X->inst]), suspend(writeln(foo),
1, [Y->inst]), 3 * X + 2 * Y #= 0.
type error in 0 + 2 * Y + 3 * X #= 0
[eclipse 4]: 3 * X + 2 * Y #= 0.

X = X{[-6666666..6666666]}
Y = Y{[-9999999..9999999]}

Delayed goals:
        0 + 2 * Y{[-9999999..9999999]} + 3 * X{[-6666666..6666666]}#=0
yes.
[eclipse 5]: 

I have a hack for fd (ugh, I hate low-level C code with unhelpful
variable names and no comments) which works around this (appears to let
me do what I want to do), but don't know whether suspend ought to be
"fixed" or not.

Cheers,
Warwick