Thank you for pointing out the typo. There were two. I believe I have fixed them.
I would like a way to include some semantics in the interface definition that go beyond method signatures. This would likely work better in languages where we can define types more precisely, like Haskell or (somewhat surprisingly) Pascal. :) I think that if interfaces carried with them a description of how they're meant to behave, then fewer people would object to "extra" interfaces, because they could carry much more of their own weight. The line between client expectations and freely-changeable implementation details would be much, much clearer.
I write contract tests as a way to add this semantic/behavior details to an interface. I think of these tests and the interface as a single, logical thing. I find that thing beneficial, even critical, no matter how many production implementations I need.