Syntactically, an interface doesn't really mean anything other than the fact that some method of a certain name exists.
Semantically, however, the power of interfaces is that they form a "guarantee" of an implementation of some method to be in accordance with the behavior described by the interface itself. That is, by choosing to implement Block or Block2, you are contracting yourself to their behavioral expectations (specifically, containing their method).
In your example, the fact that your class implements both Block and Block2 is an explicit statement that you are implementing both of them--don't be confused by the fact that their method names are the same! The syntax only tells you that the method EXISTS in Impl2. What's more important is what behaviors Block and Block2 define/expect.
For example, if you had two interfaces called List and Set, and wanted one data structure to be able to represent both semantically, you may have a size() method that is the same for both, and thus it implements both List.size() and Set.size().
Of course, interfaces are also very easy to abuse if you are not careful with semantics. You would have big issues implementing both List and Set if they defined the same add() method, because by definition, the List.add() behavior allows duplicates, and Set.add() does not. So there is a trap here--you may think you can implement both interfaces based on similarities in some methods, but it turns out they define fundamentally different behaviors in other methods.
In general, it seems to me like any time you are implementing two interfaces at the same time with the same method, something is wrong with the class design. Perhaps what you really wanted to do was combine shared behavior into a superinterface, and implement that. It would be a much stronger construct since you would be explicitly defining the shared portions of the interfaces, and wouldn't run into implementation issues with the distinct portions.