All of this is really caused by the fact that Unicode is supported, but not fully by all, apps in OS X.
Basically, Zapf Dingbats used to be just a font that substituted symbols for letters. In a letter font, you press A, you get A. Use Dingbats, you press A, you get a snowflake.
Under Unicode, the first "plane", or set, of characters defines specific code numbers for every character in a zillion languages, as well as special things like dingbats and other symbols. The letter A has one numeric ID (let's say it's 65); the snowflake that you used to get w/the A key has an entirely different numeric ID (let's say 450).
A Unicode font (or, more correctly, a Unicode-compliant font) has its characters in the assigned slots: if there's in A, it's in slot 65; if there's a snowflake, it's in slot 220.
Now, with that in mind: Select Zapf Dingbats and type the letter A. Nothing happens because there is no letter A in Zapf Dingbats--that font has nothing in slot 65. But, OS X to the rescue! When you try to enter a character that doesn't exist in the current font, it runs around looking for a font that
does have that character - and it always looks to Lucida Grande first. It finds an A, and it give you an A, necessarily changing the font as well. Of course, this all happens so fast that you don't realize there was a problem with the A and Zapf Dingbats - all you see is the font change and an A you didn't expect.
The confusion is compounded because some apps are smart enough to realize that if you selected Zapf Dingbats, you want Zapf Dingbats, and they give you the items you are typing. (Try copying a string of dingbats from Word and pasting them into Text Edit.) But take a look at the Keyboard Viewer: select Zapf Dingbats and it displays the alphabet from Lucida Grande.
Earlier OS X provided a special Z.Ding. keyboard, just as if it were a foreign language - don't know why it's not in Tiger.
We're in the midst of a big change in terms of how fonts are coded behind the scenes; it should all clear up in a couple of years <g>.