Or in detail:
You must consistently write code in the language. Knowledge without experience cannot make you a master.
You must write idiomatic code for the language. If you're just writing FORTRAN in another language, then you might be a FORTRAN master, but you aren't a master of the language you're using.
You must exploit the power of the language. If you're writing "for" rather than "foreach" loops to iterate over a collection in C# or rolling your own LinkedList class, you aren't a master of C#.
You must solve difficult problems. Writing Hello World will never make you a master.
You must write code in an easy-to-explain way. If you are the only person who can read your code, you aren't a master of the language.
* He's written a non-toy compiler for the language.
* He knows how to choose between more or less semantically equivalent ways of writing the same code because he understands the tradeoffs involved.
* He's explored many or most of the dark and mysterious corners of the language and knows when and when not to invoke them in production code.
* He is familiar with the contents of the standard library and uses it whenever appropriate.
* Knuth is his homeboy.
That's all I can think of for now.
When you know that a language is absolutely the wrong choice for a problem, you are probably there.
When you can hold a problem in your head, use two different programming languages to shape a solution, and intuitively understand - in a way you can clearly communicate at least to yourself - which one is best suited to the situation, then you can consider yourself an expert.
Mastery is just a path.
expert: biggish list of work\projects finished, know how to leverage the standard/popular libraries