Comment author: @garrigue

Actually, the problem is rather that the distinction between private abbreviations and private row types is made on a purely syntactic, and you get an error if the system guessed wrong. I agree that the guessing could be improved: in your example the object type has syntactically no row variable, so both cases should succeed; symmetrically, having several aliases should not change the behavior (but I'm not sure why one would want to pile up aliases in this way).
Note that one can already force a private abbreviation by using a constraint:
type t = private 'a constraint 'a = <x:int>

Another approach would be to do it more semantically: produce a private row type if the type has an unbound row, independently of the syntax. The problem is that it might behave in unexpected ways: a type that syntactically it looks like a private row type could end up generating a private abbreviation.
For instance the following is already accepted
type 'a t = <x:'a> as 'a
type u = private 'b constraint 'b = <x:'b t; ..>
and the semantic approach would allow
type u = <x:'b t; ..> as 'b

Comment author: @garrigue

Fixed in trunk at revision 14443, following the "Another approach".
Now all for cases are accepted, creating a private abbreviation or a private row depending of whether .. is used or not ('as' doesn't matter).