I had a similar issue and developed a fairly decent workaround.
In my situation, I have a parent view with an embedded view that is used to host custom content for equipment that is organized in a hierarchy. There is a session custom prop that points to the id of the current location in the hierarchy, and the embedded view path is bound to a query that uses that id to return the path to a corresponding sub-view.
The horizontal menu is bound to a query that uses the same id to return data about all the children of the current location - which could be 0 or dozens of children, so the built-in scrolling of the horizontal menu has much better functionality than a flex repeater.
I found that I could set the target property of each menu item to the corresponding id of that location, capture that in the event.target argument of the onItemClicked event for the menu, and there update the session prop value. This worked perfectly in Designer, although I did have to cast the id to a string to store it in the menu props, and cast the string back to an int to store it in the session prop, no biggie.
Unfortunately, in a browser, I discovered that the menu still forced a navigation, which, of course, failed. I was hoping there would be a way to abort the default navigation in the onItemClicked event, but so far I haven't figured out how.
My workaround exploits the behavior of a menu item that has sub-items. These parent menu items don't navigate, but they do still carry the event.target value to the onItemClicked handler. I found that by adding a "phantom" child item to each top-level item, which is disabled, blank, and transparent, it almost does exactly what I want.
phantom = {
'enabled' : False,
'target' : "",
'items' : [],
'icon' : {},
'label' : "",
'style' : {'opacity' : 0}
}
The only artifact is the blue selection highlight that appears and disappears if the user repeatedly clicks the same item. This is relatively subtle and unobtrusive.
One significant caveat: This only works smoothly with a single-level horizontal menu. If you add submenus and apply this same technique to the submenu items, the submenu does not disappear after the click event. The user has to click on the parent menu item again to close the submenu, which is obviously a pain. I've even gone so far as to reset the menu items property to an empty list (in my case it gets rebuilt immediately based on the property binding) and the submenu still stays open.
So, to sum, hijack the target prop of the menu items and store your parameters there. Add a phantom sub-item to each of these parent items to suppress the navigation behavior. Capture the target value in the onItemClicked event and there you can script whatever behavior you want, whether it's your own system.perspective.navigate call, or setting a property value elsewhere that stuff is bound to, or something else.