Why is exporting fixity declarations a "bad idea"?

Question

According to David MacQueen in his Reflections on Standard ML report¹,

Lexically-scoped infix directives were an ill-advised legacy from Pop-2. They complicate parsing and they do not work well with the module system because infix directives cannot be exported by structures or specified in signatures (and it would not be a good idea to add such a feature).

Now I do agree with him on the claim that private-only scoping for infix[r] declarations was a bad idea, it renders imported user-defined operators quite useless, but the solution I imagined for this was to actually export those declarations in signatures.. Not to get rid of them altogether.
Out of the languages I know to have fixity declarations (ML and derivatives, Haskell and derivatives, Prolog, ...), I'm interested in whether they document benefits and/or drawbacks to that idea. More generally, a language implementor's established design experience could bring interesting insights to the disadvantages of what seems (from a user perspective) a nice convenience feature.

So my question is, in short, are there citations and/or known issues in literature that support MacQueen's opinions on not exporting fixity?

Answer 1

One possibility is if you see something like x op1 y op2 z, you don't know if it means op1(x, op2(y, z)) or op2(op1(x, y), z). Prolog has write_canonical, which writes in pure prefix form, so you can always know exactly how something has been parsed.

There are also issues of exporting operator declarations from modules (SWI-Prolog seems to have got this right).

Other than that, I can't think of any disadvantages. There are enormous advantages in readability and consistency. For example, a variant of DCGs defines an operator -->>, similar to the existing --> ... this makes things far more readable than if everything had to be written using prefix notation.