I don't immediately see how you would create such an issue as I understand the problem statement.
The closest I can think of would be if a class implemented two interfaces which had the same method name and input parameters but a different return value - I did not try it but would expect this to result in a compile error. If the method has different parameters then it would not result in a 'collision' and as such the unique method would be invoked.
In a situation where the method name, input parameters, and return value all match and was defined in more than one implemented interface then that method would be invoked whenever invoked either as the class or as either of the interfaces. If you wanted different behavior depending on what 'context' the method was invoked from you may be able to look at the call stack to determine how it was invoked (did not explore this, just throwing it out). Not sure if it would be advisable to really do something like this if it is feasible as it would be clearer to have a different class or implementation for each interface or update one of the interfaces in order to make the method unique.
I guess you mean "simulate" instead of "stimulate".
The origin of the diamond problem is the fact that in C++ you can inherit two different implementations of a method through different superclasses. Since in Java you can't do this, you also don't get the diamond problem. There's no way to simulate it; the designers of the Java language explicitly made it so that you don't get the problem. There's no way to get the problem anyway. (If it would be possible, then there would be a design error in the language).
Java™ is specifically designed to avoid the diamond problem, so it is probably impossible to simulate. The nearest you can get is thisDamn! de Jong has got there before me! It’s only Rob who is allowed to do that!
Brian and Jesper has already explained nicely. I just want to add a situation where two interfaces have a constant with same name. Irrespective of the type being same or different, you'll get same compilation error(ambiguous field) if you access it directly from the implementing class. An example: