Eh neither side is fully right or wrong with the whole does solpartmenu render SEO code. While there is a huge misconception that solpartmenu doesnt render SEO code if my brain servers me correctly it does so via span tags around the content etc. This is SEO friendly coding but its by no means optimized SEO coding. While menu systems like HouseofNuke use full CSS styling for their format which is becoming more and more of a SEO requirement. Search engines are making a shift to opt out of some of the html tags. For example <meta> tags are almost completely ignored anymore.

Overall though either menu style / system works well for SEO purposes. What Solpartmenu does not do is render Container menus in a pure CSS skin properly. The solpartmenu in a container will render around 150 px to the right and about 50% down the module if you have a pure CSS style skin. That is why houseofnuke menu system is pushed onto skinners a bit more then normal. Also being CSS greatly cuts down your overall file size, which for the DNN system is public enemy #1. A work around though is to use the [dropdownactions] token for container menus in your pure css styled skin. While not as flashy as solpartmenu it remains functional with pure CSS based skins.

To me I use solparmenu if I am building a table based layout, but if I am going for pure CSS complaint skins / containers I use the houseofnuke menu. Beyond that really not that much difference. Now for the OP the Nav / Menu is more of a placeholder till 5.0+ is released. Seems like they started on the new Nav / Menu to fix / improve the solpartmenu issues, and decided to redo it from scratch and in order for it to fully work they need the new codebase that is coming with 5.0.

I just realized that what I said wouldn't work... the admin skin will only apply to the admin pages- settings, skins, etc.
I'll look into something and get back shortly.

edit- Did some hunting amongst other skins I have hidden away (not mine, but used for reference)....
Try substituting the following for your [NAV] token (or whatever menu token you're using) in your HTML skin::

<% If DotNetNuke.Security.PortalSecurity.IsInRoles(PortalSettings.AdministratorRoleName) %>[NAV]<% End If %>

Then re-parse the skin and set it as your portal skin.

If people are interested in what code gets rendered for the spiders it is easy to figure out.  Simply go to www.google.com,  type in

site:dotnetnuke.com

or whatever site you wish to view.

Click on the cached link for any page. 

"Now for the OP the Nav / Menu is more of a placeholder till 5.0+ is released. Seems like they started on the new Nav / Menu to fix / improve the solpartmenu issues, and decided to redo it from scratch and in order for it to fully work they need the new codebase that is coming with 5.0."

This is not true if you are referring to the differences between DNNMenu 1.0 and 2.0.  It is true that DNNMenu needed to do this for solpart.  DNNMenu 1.0 was the first release which supported things like keyboard access and populate on demand (only send down root elements.  this is how the default blue skin does its module actions.  No need to send down every module action for every module.  only load it when it gets hovered).  The differences between DNNMenu 1.0 and 2.0 are minor in my opinion.  Yes, it now requires MSAJAX simply because the ClientAPI requires it.  The new rendering mode for unordered lists is ok, but for reasons I stated prior is not really necessary.  I posted a bunch of links earlier discussing many of these topics already.

People should also not confuse Nav and DNNMenu.  NAV is a SKIN OBJECT, DNNMenu / Solpart are CONTROLS.  You can use NAV with any control (solpart, DNNMenu, Treeview, etc.)  The original Menu/SolpartMenu SKIN OBJECT was not very organized in how its properties were laid out.  NAV fixed that issue.  Regardless of what control (menu) you choose, it is recommended to use the nav skin object instead of the older Menu one.  Hope this clarifies things.

duowen,

Please take a look at this document.