Sorry for the late post to this topic. Someone should really go through the open topics and try to get outstanding questions answered. I suspect you've moved on, but hopefully someone else may benefit.

"UnknownMember" is a special processing capability of MSAS, that has some good features as well as some definiate drawbacks. You should thoroughly understand the options before committing to a production implimentation.

In your example, you're mixing your own implementation (with key values of -1) and the MSAS implementation (key value = null) which is probably the source of your confusion. Pick one method an stick with it. In general, I'd say that manually handling unknowns is probably more robust (that means, characteristics never have a null value), but there are some nice aspects to the MSAS processing.

On to "UnknownMember" handling:

Having MSAS decide what to do about null values is a little tricky (NullProcessing).

If you have it set to "Automatic", it's the same as "ZeroOrBlank". Since many (most) characteristics are strings, that means nulls get translated to an empty string and you end up with a key value of ".&[]". However, in most BI reporting tools, you end up with a zero length string for a description (i.e. "") and that can be devilishly hard to select in most circumstances. As well, you end up with an empty field on most report panes, which leads to confusion and misunderstanding.

If you set it to "UnknownMember", it gets a little better. The key value generated becomes ".UNKNOWNMEMBER" and the description becomes "Unknown", which you can easily override using "UnknownMemberName" (at the dimension level). There's even MDX components to properly identify this construct, so that you can incorporate any special handling.

What's more, MSAS has the ability to hide the unknown member, a very useful feature.

Where does it break down? It seems that pieces of the MSAS parser hasn't taken this into account. Any time you include this type of attribute into a hierarchy, you'll end up generating logical keys that include constructs like:

.UNKNOWNMEMBER.&[somekey]

or even

.UNKNOWNMEMBER.&[somekey].UNKNOWNMEMBER

Some parts of the engine handle this gracefully. Other parts throw a syntax error on the "&" symbol. (Use "SQL Server Profiler" to trace the error. even though it's perfectly valid syntax. So be prepared for some operations and tools to fail.

I contacted Microsoft on this issue a few years ago (with very heavy, complete documentation) and they ended up with the old saw "working as designed".

Still very useful, but you've been warned.