As per the description this seems to be a feature request, hence adding appropriate labels for further triaging.

I guess, but it also fixes an issue, which is more important

Thanks for your input! In most situations the system back button should take you back to the previous tabs. There are a couple cases that I can think of when it doesn't. If you have the text selection menu showing hitting back will close the menu and if you have the overflow menu open (three dot menu) then hitting the back button will close that menu. If you find a scenario where hitting back does something that you think is wrong please file a bug.

We are aware that Chrome for iOS and some other Android browsers are have the back and forward buttons in the bottom toolbar. I think it makes sense for iOS to have them since there is no system back button but for Android it seems a bit redundant although maybe having the system back button do two separate things is confusing. I'm adding some other people who are working on the bottom bar for their input.

I'm pretty the scenario(s) aren't 'bugs' though. It's not super common but, sometimes when I tap it, it will bring me out of Chrome completely and I guess back to the app I came from or back to the last active app. It's like it's not possible to go 'back' a page in these scenarios, and that's quite bad. I saw this filed a couple of years ago, does anybody reading this know the issue number? I still can't find it.

I love the system back button and I don't want to see it leave but it shouldn't be used as the 'back' button in browsers, I'm pretty sure this is why Microsoft put back and forward buttons in Edge for Android, they had the same problems with IE/Edge in Windows Phone (Windows Phone had a system back button). The system back button just shouldn't be used as the 'back page' button in a phone browser.

Thank you for this feedback, and for taking an interest in Duet.

The back/forward buttons are elements that we've considered for Duet and have chosen to omit for the time being, but would certainly be open to experimenting with in the future given significant quant/qual usability data to warrant their presence. As of today, our research has typically shown that users understand and use the Android system back button, but ignore on-screen back buttons.

It's worth noting that in the current design, the Android system back button is being used correctly. As with any other native Android app, the system back button takes the user through their backstack until it has been exhausted, as which point, it returns the user to the home screen (or previous app). If you open a non-browser app on your device, navigate around, and then tap the Android system back button a few times, you'll be able to observe this behavior.

This does leave the app-closing behavior on the table, but it is an Android pattern. Interestingly, many users intentionally use the system back button in the way described in this bug (tapping on it to see the full backstack before closing the app). One user's bug can often be another user's feature. But I think we could make a stronger case to change the Android system back button behavior than to add a redundant back button to Chrome's UI. One is a solution, the other is a bandaid.

The forward button is accommodated in the overflow menu, where it has seen intentional usage.

As with any major UI shift like that of Duet, we have limited real estate for feature placement. Deciding which features are placed in top-level UI is a balancing and prioritization act determined by the utility they provide to our users. If we find that users would benefit more from a top-level forward or redundant back button than they would from the 5 other features that we've currently surfaced, we'll make that change. We need the data to show that first though; so far it hasn't.

One experiment that we've considered is to place the forward button in the second position (replacing the Share button) in Duet. We could run this to see which feature is more useful at the top level.

I'd also love to open up the floor for ideas and data (or anecdotes) that you'd like to share. Please feel free to mock up how you'd design Duet and what you'd experiment with. Which features would you move or omit, in order to accommodate the back/forward buttons? If you could change the Android system back button behavior instead, would you prefer that? I'm totally open to your input here.

It's true it would be redundant but there are redundant back buttons all throughout Android apps, it's something users quickly get used to.
If this 'back' swipe gesture ships, it will solve the issue I described (I still really wish I could find that bug!). I really, really hope this makes it to Stable
https://www.androidpolice.com/2018/11/29/gestures-for-page-forward-back-may-be-coming-to-chrome-for-android/

In the mean time, I wish everyone reading this would try Edge (don't worry, it's just Chromium with a different UI) because having that seperation between the browser back button and Android system back button is just nice, it gives you 100% confidence when you tap it, you know it's going to do exactly what you want. 

Sorry for double posting but I forgot to add: if that 'back' and 'forward' swipe gestures ship, you could probably remove the 'forward' button from Chrome. At the moment, you have to tap twice to go forward a page and that's just too much, a 'forward' gesture is better in every way. 

Over to lzbylut to process the feature request.