The standard argument against such a practice is, again, that it breaks encapsulation: "I am dealing with a type, I don't care if it's an interface or a concrete type."

It sounds good, we don't do such discrimination in real life with peoples, animals and stones for instance.

Well, you should, because they are not equivalent. For example, you cannot "new" an interface, and it's the kind of information I would like to have right off the bat

This is the same for abstract classes, singleton, most of the utility classes, but we don't use AMailMessage, SORB or UStrings. Of course it's an important information, but should we rely only on naming schemes to provide us the vital documentation? An API, a product, is more than just a set of interfaces and classes, it comes with a vision for solving a problem. You don't get that vision with only names, and once you get the vision, I think you don't really need this "I".

There is no harm in distinctly flagging your interfaces with an "I", I believe it makes the code much easier to read because you can now see clearly which part of it is reusable and adaptable as opposed to your own private implementation.

Yet there is in fact no real harm, refactoring tools can handle nicely, even if would like to be able to put easily a comment everywhere the refactoring tool let its footstep. And such a naming scheme is easier to enforce than a good documentation. As for seeing which part is reusable and adaptable, I've seen a product where all the classes from the public API were prefixed with "API", that made the documentation unbrowsable quickly.