Looks like [ToolbarButton updateHiddenInCurrentSizeClass] is getting called multiple times with UIUserInterfaceSizeClassUnspecified and setting all the buttons to hidden.  

updateHiddenInCurrentSizeClass is being called with an unspecified traitCollection because [PopupMenuPresenter dismissAnimated] is calling:
   [self.baseViewController.view layoutIfNeeded];
during the animation. 

Is it possible that's related to the error?  It seems like commenting out the layoutIfNeeded above fixes the bug, but I assume that causes other problems.

Thanks for digging.  Sounds like this is what's going wrong:
1) The popup menu presenter invokes layout when the size class is Unspecified.
2) AdaptiveToolbarVC hides all of its buttons when the size class is Unspecified.
3) iOS 10 somehow breaks UIStackView's constraints when all of its subviews are hidden.

#3 is out of our control and fixed in iOS 11.

#1 and #2 both seem like bugs, but I'm not sure whether the current behavior is important to maintain in some cases.

https://chromium-review.googlesource.com/c/chromium/src/+/1097207 attempts to avoid triggering #3 by preventing the stack view from shrinking to zero width.  I think this is pretty safe as a temporary change.

Yes, I've also seen updateHiddenInCurrentSizeClass is indeed called multiple times. I suspect that UIStackView's automagic relayout when the views are hidden doesn't happen correctly as the buttons are hidden and unhidden multiple times during one runloop. 
It is really hard to make them update their visibility only once, though, since there are so many code paths leading to updateHiddenInCurrentSizeClass, including some snapshotting calls and animation callbacks and stuff. 
I agree with Rohit that the proposed fix is good enough, since we understand the problem for the most part and the solution is a workaround for an iOS 10 bug.

Going forward, I think the toolbar should be audited for the redundant calls to updateHiddenInCurrentSizeClass, and possibly some special-case handling should be introduced for the unspecified size classes, or fake trait collections need to be injected where appropriate. If this enables us to remove the workaround, that's great. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8b0446e6d03446934b11236a768082bad8968814

commit 8b0446e6d03446934b11236a768082bad8968814
Author: Rohit Rao <rohitrao@chromium.org>
Date: Wed Jun 13 08:30:08 2018

[ios] Fixes toolbar buttons disappearing when switching BVC modes.

When switching between incognito and non-incognito BVCs, it is possible
for all of the toolbar's buttons to be temporarily hidden.  We believe
that this results in the stack view having zero width, which seems to
permanently break autolayout on iOS 10.  Adding an optional width
constraint seems to work around this issue.

BUG= 851954 

Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I6995f2b3f5fa3b0f2eafb09e3970001fd16720f6
Reviewed-on: https://chromium-review.googlesource.com/1097207
Reviewed-by: Stepan Khapugin <stkhapugin@chromium.org>
Commit-Queue: Stepan Khapugin <stkhapugin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566759}
[modify] https://crrev.com/8b0446e6d03446934b11236a768082bad8968814/ios/chrome/browser/ui/tab_switcher/tab_switcher_transition_egtest.mm
[modify] https://crrev.com/8b0446e6d03446934b11236a768082bad8968814/ios/chrome/browser/ui/toolbar/adaptive/primary_toolbar_view.mm

To Gauthier since this is in the toolbar. Let's discuss when you're back in the office. It'd be nice to get rid of this workaround and come up with a better solution. 

Looking at the CL, as long as it is behind an iOS 10 only guard, I am fine with it.

Verified based on the steps from original report.
Toolbar looks good.
Verified in iPad 5th Gen iOS 10.3.3
M69.0.3465.0 dev