Skin objects and navigation providers are different.  Nav.ascx, SolpartMenu.ascx, TreeViewMenu.ascx are examples of skin objects.

The Nav skin object may be used with any navigation provider.  

Your choices in navigationproviders are Solpart, DNNMenu, DNNTree, DropDownList, and ASP2Menu.

The solpartmenu carries some baggage due to backwards compatibility.  One of those things is that it gets its arrow images from the systemimagepath.

If you are ok with your arrow images inside the systemimagespath, then you can use solpart, if not, then you need to use a different provider.

As migration towards the Nav Skin Object is encouraged, so is migration towards the DNNMenu (away from Solpart).

For a little background on the move towards the DNNMenu see this blog.

I should state here that there did exist another property in the SolpartMenu Skin object called UseSkinPathArrowImages that would allow solpart to use the skin's path instead.  However, this required ALL systemimages (i.e. spacer.gif) to be in the skin as well.  Since the arrow is not really a system image, the two were uncoupled in the DNNMenu

They do use the same syntax, meaning they all use the same properties.   As far as how they use these properties, they are similar but not exactly the same.  It seems that you would be in favor of either breaking backwards compatibility for solpart (not having arrows in systemimagepath) or restrict the DNNMenu to have this same limitation...  The whole effort towards the new objects was meant to clean things up as much as possible, this dictates that some functionality will be different with the new objects.

My suggestion would be to simply use the DNNMenu.  This is of course assuming that Solpart does not currently have a feature that the DNNMenu does not.  (Eventually DNNMenu will have more features)

Question:  If you specify a IndicateChildImageRoot and IndicateChildImageSub with the Nav skin object and the SolpartMenu navigation provider does it work?   (It does for me).

If I am understanding you correclty, you are having issue with the default arrows being applied to the nav skin object.  You are saying that the default should not include the [APPIMAGEPATH] portion, right?  I am saying that if I remove that, the DNNMenu will no longer have the correct default arrow path, so one will always be wrong. 

That at least was my understanding before digging further in the code...  The reason removing the APPIMAGEPATH will still work with the DNNMenu is due to a hack that needed to be added to the DNNMenuNavigationProvider when it is used for module actions.

'solpartactions has a hardcoded image with no path information. Assume if value is present and no path we need to add one.

If Len(IndicateChildImageSub) > 0 AndAlso IndicateChildImageSub.IndexOf("/") = -1 Then IndicateChildImageSub = Me.PathSystemImage & IndicateChildImageSub

If Len(IndicateChildImageRoot) > 0 AndAlso IndicateChildImageRoot.IndexOf("/") = -1 Then IndicateChildImageRoot = Me.PathSystemImage & IndicateChildImageRoot

This unfortunately is necessary, which of course causes the DNNMenu to use the system path, like solpart.  I guess it was a tradeoff I forgot about... the DNNMenu allows for an alternate path, it just does not support using the current path (one without a /).

So, to bring this issue to a close, you are requesting that the default APPIMAGEPATH be removed from the arrow paths in the nav skin object? 

Also, there is an easy workaround (specify an image), correct?

If I decide to have a image in my homedirectory [HOMEDIRECTORY] and [SKINPATH] just DNN works.    Solpart refers to /images//Portals/5/Skins/Skin/kopp.gif 

...

The best was if both DNN and Solpart used the same syntax. Why not in nav.ascx.vb set the right path depending on provider.

I already mentioned earlier in the thread.

The solpartmenu carries some baggage due to backwards compatibility.  One of those things is that it gets its arrow images from the systemimagepath.

They do use the same syntax, meaning they all use the same properties.   As far as how they use these properties, they are similar but not exactly the same.  It seems that you would be in favor of either breaking backwards compatibility for solpart (not having arrows in systemimagepath) or restrict the DNNMenu to have this same limitation...  The whole effort towards the new objects was meant to clean things up as much as possible, this dictates that some functionality will be different with the new objects.

Also, this blog covers some reasons why different providers will have different outcomes.

It has never been a guarantee that switching out a different provider will result in the same look and feel.  Hopefully this is obvious for cases where you swap out the SolpartMenu for something like the DNNTree.  For the swapping of the SolpartMenu with the ASP2Menu (or DNNMenu) it may not be as obvious, since they are of the same control type.  Each control may handle their styles differently.  An obvious example of this is the quirky way Solpart handles borders around menu items.  Skins like the default DNN Blue that are included in DNN have classes defined to handle this border issue.  If you were to substitute the ASP2Menu by ProviderName="ASP2MenuNavigationProvider" everything will work, however, you will see that the menu has some quirky border issues, which can be fixed by removing the border entries for the css of the skin.