Naming Standards – Using ‘Is’ Prefix and ‘On’ Suffix in Non-Hungarian Naming

Your last point is the most important - whatever you do you need to be consistent across your project and with your colleagues. There are two main ways to acheive consistency and if possible you should use both. Firstly use a tool to check naming conventions at build time. In the .Net world StyleCop would be a good example of such a tool. The second way to get consistency is to have peer reviews of all code, so that you can all keep a look out.

Your other two points seem to be asking about an alternative. I'm not sure you need an alternative; the point about Hungarian no longer being popular is that it used to be used to descibe the type when the type system and tools were a bit, shall we say, less strict. I.e. if you were programing in C and passing pointers around the only way to keep track of the type was by using Hungarian. Now, if you are using a language like C# or Java you will not be using pointers (or very rarely), so the need for any kind of Hungarian goes away. Also, modern IDEs let you see the type very easily by hovering over the variable or at worst using some short cut to see the original declaration. So, I don't think you need any kind of notation, just name the variable by what it does. If it's an email address just use "email" or "emailAddress". If it's a customer name just use "customerName" etc.

I think this may well be the only case when prefixes are useful.

Classes and interfaces really do have different semantics, and because both are types, are easy to mix up.
When I see a class declaration, I can instantly tell what it derives from and what it implements:

public sealed class ActivityCollection : List<Activity>, 
    IList<Activity>, ICollection<Activity>, IEnumerable<Activity>, 
    IList, ICollection, IEnumerable

It would be harder to understand if the definition looked like

public sealed class ActivityCollection : ListClass<Activity>, 
    List<Activity>, Collection<Activity>, Enumerable<Activity>, 
    List, Collection, Enumerable

And how would you call ListClass? Clearly it's not just ListBase because it's usable on its own.
So, we either have to solve a problem we just invented, or adapt a prefix that separates classes from interfaces, which is what .NET Framework designers did.

Also, personally I find it useful when I can tell from the method signature that it works with interfaces.

public void PrintLines (IEnumerable<string> source)

It's like a signal to my head: hey, I can implement this! I can feed the method whatever matches the contract.

Of course one can argue it's not that important but this is one of those little things that make the prefix worth it for me. It's especially useful when writing a lot of code with IoC containers when you constantly work with interfaces and need to easily differentiate between the two.

By the way, not only the interfaces have prefixes in .NET type system. Don't forget about the generic type parameters:

public delegate TResult Func<in T, out TResult>(
    T arg
)

This is another situation when it's extremely useful to be able to differentiate between classes and another kind of types.