BottomBar allows us to define a set of Screen navigations behind it, but clicking on a BottomBar Item is like clicking on a menu; Each BottomBar Item doesn't retain a history of the last screen/scrollTop location - it is always a reload to the first linked screen, and not the last screen the User was on for that BottomBar Item's context.
For that, we would use Tabs. Except with Tabs, you can't define the navigation within it with Screens. You'd have to use Blocks (of Screen content) and create a conditional variable to swtich between them, track the Stack (navigation path) to push/pop off of, override the Back button, and store/restore the ScrollTop location for each Block. Lots of work and hard to maintain.
Would be great if we had the option to design like BottomBar (define linked screens) but at Publish/compile time, it outputs behavior like Tabs (with each Tab having its own StackNavigation - remembering the last Screen it was on as well as the ScrollTop location).
Here's some explanations:
https://docs.google.com/presentation/d/1V7gxMPBVxo4TyoytXtiuO_3knHF2bj9zlxT9_3HT4Vc/edit?usp=sharing
The AirBnB app does this with at least 2 of its Tabs (keeps the last context), while at least 1 Tab acts like BottomBar Item (reloads the page upon selection).