I've taken some time to review the LayoutMenu components and here are my findings.

ContentStack

• it is not immediately clear to me from the TLD doc what "singleView" attribute is use for?
• the two columrn and one column example in comp-test don't seem to use this attribute
  consistently

ContentPanel

• "menuOrHome" does not seem to be necessary, both conentStack and layoutMenu have the notion
  of a selected pane, currentId and selectedPane respectively which are used to define the currently
  selected pane.

LayoutMenu

• should be renamed to contentStackMenu so the association with ContentStack is more clear.
• child mobi:layoutMenuItem should be renamed mobi:contentStackMenuItems to be more
  consistent with the series pattern.
• a new component mobi:contentStackMenuItem should be created to allow menu's to be defined
  in the view without an Bean value binding.
• layoutmenu has a selectedPane attribute which seems redundant, as the associated panelStack
  reference by Id has the same value binding.

ContentNavBar

• when manually manipulating the currentId and selectedPane value binding via an action the
  "menuButtonTarget" is no longer respected and navigation is always to the "menuOrHome" definition.
  refreshign the page shows the correct page.
• menuButtonTargetId atribute should line up with the name as define in contentStack/contentPane,
  I would suggest targetContentPaneId

Updated Tests

• layout/layoutMenuSingleIncludes.jsf
• splash, data/time and tabset pages all have a new button "goto page panel 4", click this button
  takes the user to panel4. The panel 4 contentPane has a child contentNavbar with a
  menuButtonTargetId="panel3". However when clicked on the menu panel is shown.
• onclick="mobi.layoutMenu.showMenu('stack1', {selectedId: 'panel3', singleSubmit: true, client: false, single: true}

  );

• the above JavaScript look fines but the execution seems to be incorrect.

• layout/layoutMenu2.xhtml
• added <h:commandButton /> with navigation to panel3, same behaviour as above.
  back button should point back to panel3 which doesn't seem to work.

Answers to last comment:-
ContentStack
-singleView is only significant if you have a single column stack which must contain the menu. Otherwise, you can have as many columns in your layout that you want or have room for. Samples in mobitest only show this attribute in the singleView examples since it defaults to "false". No need to have it in the markup for anything other than a singleView layout.

ContentPanel
-menuOrHome denotes the panel you wish to configure with the "menu" button option on the contentNavBar. If a panel is denoted this, then the menu (or home or whatever you want to call it), will automatically be the selected id when pressing it. It is necessary if you want to always be able to find "home/menu".

LayoutMenu
-agreed on rename which I had proposed several weeks back, but then everyone else deemed it was not necessary at the time.
-good idea to allow the single feature of the item.
-perhaps a defaultPane attribute would be better than a selected one?
-was considering allowing the contentStack to do the entire thing and just have the menuItems declared within it, but wasn't sure how to accomplish it. (not having the menu component but an attribute that would determine the menu was to be used with it and take all attributes from the contentStack and it's children).

contentNavBar
-If your panel is designated as menuOrHome="true" then the menu button will always take you there.

• perhaps another type of button (navButton?) that would allow you to go quickly to any other page (I was considering previous as a button here but was waiting for your feedback

UpdatedTests.
-will take a look but you may want to consider the notes above and then revise tests again, so let me know. Test on layout/layoutMenu2.xhtml definitely sounds like something that needs to be fixed.

singleView for contentStack component is now determined and state-saved by ContentStack component. If it has a child that is the contentStackMenu, then it assumes a singleView. Otherwise, it may have a contentStackMenu which is a sibling (> 1 column) or no menu component at all.

Problems identified on tests above were not updating the value on the server, so problem was in the tests themselves. WHen a contentPane has client="true" and then pushed a contentPane that has client="false", the update script tag can be clobbered by domdiff, so added hashcode to ensure the script is there for the update.

to be completed after 1.1 final

styling strategy as I just re-used existing css for list, buttons and accordion-style menu (will assign the jira for accordion for you, unless you want an entirely new jira for styling strategy and just link to these components?). Components that are related in this endeavor are contentStackMenu, contentMenuItem, and contentNavBar

some basic styling updates for the contentPane have been checked in. For the contentNavBar and contentMenuItem, I think we should avoid copying and pasting any css into new class rules, and instead just use the existing style classes. For the contentMenuItems, you can render 'mobi-button' along with whatever style you want, such as 'mobi-button mobi-button-default' or 'mobi-button mobi-button-important'. For the contentNavBar, perhaps you should render the 'mobi-pagePanel-header' class.

any further issues with these components should be opened with specific jiras describing those issues.