Nikita: do you have an implementation of your suggestion, or is it just
a 'bright idea'?

Just an idea for discussion with hope to interest enough people to draw in attention and probably get to implementation or at least to come up with collectively approved proposal.
 
I'm not sure you've fully characterised all the current difficulties.
(For example: what is to be the principal type for your anonymous records?
 Are two records with the same-named fields, and at the same types,
 but in a different l-to-r sequence to be treated as 'equivalent'?)

I wanted to keep the introductory message as succinct as possible, so I eluded details like that. The types should be determined both by field names and their types, and since field names are by definition unique the order in which they appear shouldn't matter. E.g.:

(a :: Int, b :: Char) is the same type as (b :: Char, a :: Int) and a different type from (z :: Char, x :: Int).
 
I don't see you comparing your suggestion to others. (As Christopher
noted, it does at first sight look like TRex. Do you understand why TRex
was abandoned?)

Christopher's notion was my first introduction to TRex, so I'm far from knowing much about it, but it in fact does look crazily similar to the current suggestion. From what I've read so far, it hasn't been abandoned, it just has only been implemented in Hugs.
 
There's a substantial body of recent debate and suggestions at
http://ghc.haskell.org/trac/ghc/wiki/Records . This [Northern] Summer's
GSoC project on OverloadedRecordFields that Wvv ref'd is just one point in
the possible design space. You can trace backwards from those wiki pages
to many threads of discussion.

Thanks! This page actually says that it only addresses namespacing and doesn't approach the first class record types problem, which this suggestion does approach. For this problem it refers to a more general page: http://ghc.haskell.org/trac/ghc/wiki/ExtensibleRecords - on which TRex is actually mentioned as having a high implementation cost.

From what I've seen OverloadedRecordFields looks very much like a workaround and it does not approach the first class record types problem. Very far from the elegance of TRex.