Tabs in the app and tabs in the menu? That concept is even worse.
Like I said, the details are debatable, but the general concept is good. It solves all of the navigation related problems in a way that actually works:
- it doesn't use left/right swiping gestures for navigation, leaving those gestures for use by the app
- it doesn't add any extra chrome to the UI, not even an extra button (neither a hamburger button on top, nor a button in the bottom app bar), staying true to the content over chrome philosophy.
- it fits in nicely with the things WP users already expect to find in the ellipsis menu (app-level features that aren't specific to the current page)
- it can host any number of entries. With more entries the menu becomes taller, with fewer it's shorter. If the app has only three such entries, then all of them stay at the bottom of the screen, making them easily accessible when using the phone with only one hand, even on large phones.
- the OS can automatically map the contents of the navigational menu to a side bar, when the app runs on a larger screen, without the developer having to do anything at all.
- I can go on, but I'll leave it at that for now
Unless a solution addresses all of those issues (and two or three others I've omitted for brevity), it's not a solution.
The only two points I've seen you make against the concept I linked to (beyond the usual "I'm confused and I just don't like it", which I couldn't care less about) are these:
- it's a two stage menu (A: swipe up from bottom app bar to open, B: swipe to the desired section, C: tap the desired menu entry)
- having two pivots on screen at the same time (as shown in the concept images) is confusing
For an app that requires a navigational section, I'd assume that to be what the bottom app bar opens up to by default, meaning most of the time there will be no extra swipe. The extra swipe to access something like the options section seems tolerable to me. Office for Mobile does something very similar, so we'll be getting used to two stage menus either way. In another thread you stated you weren't aware of MS taking that approach in Office Mobile. You probably missed it because it's not implemented using a Pivot, but with a Flyout menu. That Flyout menu provides access to multiple sections of the ribbon (home, insert, design, review, etc). That's actually a three stage menu (tapping to open the Flyout is an extra step), so this is actually better than Office for Mobile's approach.
As for your point that you find it confusing to potentially have two pivots on screen at the same time (as shown in the concept), well, I partially understand that. I just don't think it's a huge problem that anybody with a little imagination couldn't easily solve. Already today UI elements from the underlying app remain visible when the bottom app bar is opened. I've never heard anybody say they were confused by that. Even the most mentally challenged user will eventually realize that taping anywhere outside the menu won't do anything except close it, but I agree that doing something more can't hurt. Maybe the OS could apply a slight darken and shrink-effect to whatever is on screen when the menu is opened, like it already does for flyout menus. That would provide an extra visual cue as to what elements can be manipulated when the menu is opened. Even if somebody is so deranged as to not intuitively grasp what's going on, the fact that the OS won't allow touch input to manipulate the app's pivot while the menu is opened seems like a perfectly suitable safeguard that will eventually explain itself to anyone and everyone.