Q: Should the provider of an interface also provide a mock implementation for testing? We wasted a lot of time on our last integration test on a bug that I think should have been found in unit testing. The problem was that an interface / service we called behaved different than we expected and the unit test didn't find this problem because we mocked that interface for the unit test and our mock was of course based on our mistaken interpretation of what the interface would do. Now I could be a bit angry at our dear coworker who provided the interface, because their description / specification of it (a terse JavaDoc comment) was ambiguous and contributed to our misunderstanding. On the other hand, I thought that the problem could have been avoided if those same coworkers had provided a mock implementation of their interface which we could call in our unit testing. Then the bug would have shown up much earlier and a lot of cursing could have been avoided.
Now, what's the best practice in organizing the creation of mock objects among teams who provide and use shared interfaces? What are your experiences?

A: 
Should the provider of an interface also provide 
  a mock implementation for testing?

No, but the provider should also provide the sourcecode for their unittests. Reading these unittests you will get a good impression how the library should be used. Maybe you can add unittests to the provider-tests in order to specify what you expect from the provider.
There are many mocking tools/framework out there that can implement a fake/stub/mock.
Asking the provider for a mock implementation has no good cost/benefit relation because he cannot know which part of the fake implementation must be nearly identical to the real implementation and which part is just facade.
An other way around this is if the provider uses codecontracts to make sure that the lib is used in the specified way.

A: Ideally, yes.
Anyone who writes code that other people use is not bound to provide anything complementing the code. However, if you want people to use your code (and everyone should always be writing with this mentality), extensive relevant documentation - which may include examples - are extremely useful.
I don't think I've ever read documentation and have thought, "This is stupid; there's way too much documentation." People are naturally gifted at skipping over what they deem unnecessary. We, however, cannot simply mind-read and interpolate the documentation or concepts that have not been explained. So, it's safe to assume: there's no such thing as too much good documentation. It should also assume that the person reading it as a naive infant (i.e. make it as simple as possible).
Examples on how to instantiate and use a class is always helpful. Although, if the code relies too heavily on the documentation to be understood, that is another (separate) issue.
This answer shouldn't be seen as firepower that will justify yelling at your co-worker. It is merely a guideline of what I think is beneficial and should be done. While this is completely useless in your situation (although, I feel your question is basically a rant), the next best thing you can do is lead by example and hope your colleague comes around.
