put (x: ELEMENT; key: STRING) is
                     -- Insert x so that it will be retrievable through key.
             require
                     count <= capacity
                     not key.empty
             do
                     ... Some insertion algorithm ...
             ensure
                     has (x)
                     item (key) = x
                     count = old count + 1
             end

Also.  I don't quite agree that ensurances should come first (contrary to Eiffel), but granted, using the embedded technique where ther contracts are blended in with the rest of the code, it may be a better technique for readability. Maybe.

It's also striking how much use of contracts can be devoted to the type constraint for reference types that nullness not be part of the domain. How nice it would be with a simple language extension, even if only interpreted as a contract

     add (Point! x)

It's again the annoying wrong-default situation; as with of nullness over non-nullness there's also the variance over invariance (well, im/mutability if you will).

That Code contracts actually implements the old- and result-semantics is very nice. 

Can we now expect .Net to be littered with Code Contracts all over for increased code correctness?

(oops, there goes the beautiful formatting heh)