The strength of macOS' menu bar is that the menus it contains are static — an application shows all options at all times, greying out the ones that aren't currently available, as a means to enabling all functions to be discoverable at all times. This means that the ability to discover and access an applications functionality is not constrained to requiring an open window, as is the case on Windows and most Linux applications.
If the left menu replicates macOS' top menu, it does so with one weakness: it is constrained by both the presence of a window and the vertical height of a window. This has two knock on effects: (a) that every window an application can present, particular document-based applications, redundantly replicate the menu in every window; and (b) that small windows cannot show the menu in a sidebar. This leads to a user interface full of surprises — can a window show all in its menu? Can a window even have a menu? If a given window is unable to show a window, should another mechanism be used instead?
The alternative is to present the left menu as a global sidebar, like macOS' Notification Center or Windows 10's Action Center. However, this has two major disadvantages: (a) it's a huge waste of space to have a sidebar wide enough to show a reasonable amount of text along the horizontal axis at larger text sizes (especially on systems that support adjustable system font metrics), and (b) the size of the clickable targets is vertically smaller and more finicky to reach than the (relatively) wider horizontal dimensions of text shown along the top (or bottom, for that matter) edge of the screen.
That issue could be remedied by the use of buttons with icons. However, this combines the existing, space-efficient toolbars with the left menu's horizontal screen waste — it takes two paradigms and makes them mutually worse.
Of course, the waste-of-screen-space issue can be mitigated by making the menu disappear after a menu item is interacted with, like Office's File menu, or make it abled to be pinned, staying visible until dismissed manually. However, this now means the user has to manage a part of the user interface that was previously handled automatically, far from ideal. Also, if the menu is able to be pinned and presented as a global sidebar à la Notification Center/Action Menu, should it come and go depending upon which application is visible? If so, how should the left menu interact with existing windows that may be occupying its space? Cover those windows or move them to the right? The former still means the user is required to manually manage something that should be automatic, the latter means that the user loses control over the placement of their windows.
Speaking of window control, I've mostly been thinking about what the left menu would look like for existing window systems where user can place windows freely. Desktop Neo proposes tileable windows similar to macOS' full screen app windows — how should the left menu be presented? If presented per-window, there will be quite a lot of wasted screen real estate; if there's a global menu bar, it would probably reserve a certain amount of the left side of the screen, taking away a significant amount of space that should be for the tiled windows — unless it dynamically resizes all tiled windows horizontally which could be computationally expensive if one of the windows is graphics-intensive, such as a game.
Finally, a layout with vertically-small menu items displayed in a list as the initial way access the functions of an application, rather than as submenus, seems ergonomically finicky for use on a keyboard-and-mouse oriented system, and touch-oriented systems are better off with touch-first navigation hierarchy-oriented user interfaces backed by scrollable lists (as per iOS and many Android apps), exposing an application's functionality in a different way altogether.
This left menu seems to be no more than a hamburger menu, though one with constraints compared to existing solutions such as in Firefox and Chrome today. As an alternative to both per-window top menus and a global top menu, it falls flat ergonomically.
If the left menu replicates macOS' top menu, it does so with one weakness: it is constrained by both the presence of a window and the vertical height of a window. This has two knock on effects: (a) that every window an application can present, particular document-based applications, redundantly replicate the menu in every window; and (b) that small windows cannot show the menu in a sidebar. This leads to a user interface full of surprises — can a window show all in its menu? Can a window even have a menu? If a given window is unable to show a window, should another mechanism be used instead?
The alternative is to present the left menu as a global sidebar, like macOS' Notification Center or Windows 10's Action Center. However, this has two major disadvantages: (a) it's a huge waste of space to have a sidebar wide enough to show a reasonable amount of text along the horizontal axis at larger text sizes (especially on systems that support adjustable system font metrics), and (b) the size of the clickable targets is vertically smaller and more finicky to reach than the (relatively) wider horizontal dimensions of text shown along the top (or bottom, for that matter) edge of the screen.
That issue could be remedied by the use of buttons with icons. However, this combines the existing, space-efficient toolbars with the left menu's horizontal screen waste — it takes two paradigms and makes them mutually worse.
Of course, the waste-of-screen-space issue can be mitigated by making the menu disappear after a menu item is interacted with, like Office's File menu, or make it abled to be pinned, staying visible until dismissed manually. However, this now means the user has to manage a part of the user interface that was previously handled automatically, far from ideal. Also, if the menu is able to be pinned and presented as a global sidebar à la Notification Center/Action Menu, should it come and go depending upon which application is visible? If so, how should the left menu interact with existing windows that may be occupying its space? Cover those windows or move them to the right? The former still means the user is required to manually manage something that should be automatic, the latter means that the user loses control over the placement of their windows.
Speaking of window control, I've mostly been thinking about what the left menu would look like for existing window systems where user can place windows freely. Desktop Neo proposes tileable windows similar to macOS' full screen app windows — how should the left menu be presented? If presented per-window, there will be quite a lot of wasted screen real estate; if there's a global menu bar, it would probably reserve a certain amount of the left side of the screen, taking away a significant amount of space that should be for the tiled windows — unless it dynamically resizes all tiled windows horizontally which could be computationally expensive if one of the windows is graphics-intensive, such as a game.
Finally, a layout with vertically-small menu items displayed in a list as the initial way access the functions of an application, rather than as submenus, seems ergonomically finicky for use on a keyboard-and-mouse oriented system, and touch-oriented systems are better off with touch-first navigation hierarchy-oriented user interfaces backed by scrollable lists (as per iOS and many Android apps), exposing an application's functionality in a different way altogether.
This left menu seems to be no more than a hamburger menu, though one with constraints compared to existing solutions such as in Firefox and Chrome today. As an alternative to both per-window top menus and a global top menu, it falls flat ergonomically.