Personally for me it"depends". Usually I would prefix everything with the word Character to keep things consistant, however if you have everything already under the Character namespace the Character prefix could seem redundant.

I could easily see going with the shorter convention of Models.Character.[X] if there never will be another class called Details, if there for instance could be UserDetails then Details and UserDetails could be confusing when looking back at the code weeks or months from now and I would personally prefer then the CharacterDetails option.

In the end it is your personal preference, what more accurately describes your domain, Details or CharacterDetails?

Personally I d stick with the second method as that is what namespaces are for: grouping related sets of classes. The first method is just making the class names longer with negligible benefits.

Your namespace already is grouping its classes under the Characters umbrella, so I would not name your classes with the Character moniker.

There is probably no right or wrong answer here. I find myself prefering your first style, but I have used the second style as well. I think in this specific situation if I were a caller of your API I would find it easier to read code that used the first style.

It is really a personal preference.

I would favor

CharacterDetails
CharacterSprites 
CharacterAppearance 
CharacterClientRights 
CharacterServerRights

Because it is more readable.

You are typically going to have a using statement of

Models.Characters.Appearance

Unless you are going to do the full notation.

I would favor anything that would increase readability. It might matter on the project and the team you are working with. If it is just you than do what you like best and would help you maintain the code in the future.

As long as you pick one and consistantly use that throughtout your code, then whichever one you choose is the right one.

My personal choice is your second option. If your namespace is character, I see no reason to use the prefix character in the class name.

Think about ambiguity that may be created by naming class. For example if I have a class called "Thread" denoting "CharacterThread" (hypothetical) and if some other class uses two namespaces

Models.Characters System.Diagnostics

I will have to fully qualify the Thread name everytime I use it ... which can be a pain sometimes