See discussion above on public property for setting implementer used by abstraction.

Being a structurally simple pattern, there is not much opportunity to get it wrong.  However, I have seen a couple of problems in some implementations.

The operation which the refined abstractions should perform should be in the interface/abstract-class with a MustOverride designation.  It should not be optional that the refined abstraction implements it or implements it with its own unique method signature.  By leaving it out at the interface level, you leave it up to the programmer who develops the code for each refined abstraction to decide how to implement it or whether or not to.  You lose the robustness and pattern-safety when you do that.

The other issue is that the Bridge pattern (contrary to its name) is all about action.  I do not believe that a bridge pattern properly applies to an abstraction or implementation which does not have methods which act hand in hand.  If one object-hierarchy (or COG) is state-based and the other is method-based, then I do believe that you should take a second look at the flyweight pattern to see whether it fits your needs better.

Finally, when teaching or demonstrating the Bridge pattern, you should be sure to highlight the common signal language which should be spoken by both abstractions and implementations.  This brings out the pattern more forcefully.  Also, be careful to demonstrate several concrete implementation and several refined abstractions so that your audience gets the idea that both abstractions and implementations are interchangeable (within their own type).  Otherwise, your students may liken the pattern to a screw-driver-handle with swappable screw-driver heads, which is a weakening of the pattern.