[BottomNavigation] [Beta] Why does controller modify embedded controllers' additionalSafeAreaInsets rather than constraining their views above the bar?

[CapnSpellcheck]

Feature Request/Suggestion

Why does the beta BottomNavigationBarController use VC's additionalSafeAreaInsets as mechanism to control height of child VC's view? Why not just use constraints? The approach doesn't even handle case of < iOS 11 & no ScrollView.

There is this seemingly inaccurate comment above -updateNavigationBarInsets:

This will ensure that although the child view controller's view is positioned behind the bar, it can still lay out its content above the Bottom Navigation bar.

It's inaccurate because the 2 views, navigation bar and child VC's view, are siblings AFAICT, both direct children of bar controller.view.

From what I can tell, only reason to allow this overlap would be to support bar transparency. However, neither iOS nor Material specs ever suggest the use of translucent tab/"bottom navigation" bar, that could be very confusing with certain background content color.

However, if supporting translucent bars is the reason for the current approach, and is in fact a requirement, there could at least be an option to enable an 'opaque layout mode'.

Additional context

I tried this patch on my branch and it seems to do what I want:

   [self.view.leftAnchor constraintEqualToAnchor:self.content.leftAnchor].active = YES;
   [self.view.rightAnchor constraintEqualToAnchor:self.content.rightAnchor].active = YES;
   [self.view.topAnchor constraintEqualToAnchor:self.content.topAnchor].active = YES;
-  [self.view.bottomAnchor constraintEqualToAnchor:self.content.bottomAnchor].active = YES;
+  [self.navigationBar.topAnchor constraintEqualToAnchor:self.content.bottomAnchor].active = YES;
 }
 
 /**