thank you for the thoughtful reply!
Boilerplate: the new API update in January creating listeners to ‘focus and blur’ events is an unnecessary layer to account for the fact that this library kills access to React lifecycle methods of screens.
we need to keep the screen components mounted, so there must be another layer on top of lifecycle events. we aren’t unmounting a component when we navigate away from it to another screen in a stack and so lifecycle events don’t make sense. if you don’t want to use those events directly, use the withNavigationFocus HOC. there was a huge amount of discussion on this already in https://github.com/react-navigation/react-navigation/issues/51 and we settled on listeners. there was also a rfc. i’d love it if you have some alternative solution if you could post a rfc with the details.
confusing API/redundancy: The navigation prop actions (e.g. Reset, GoBack, Navigate actions) are confusing. If I want to pass subsequent actions in these, do I import NavigationActions or do I just call it from my navigation prop, like this.props.navigate()? A PR was recently accepted added more layers by passing a key = null to perform some kind of secondary reset to the state ? And why is there a routename AND a key? Can we not just use a directory-style path like Root/TabNav1/Screen1 ? What is the purpose of the key.
there are a lot of questions here. i’ll start with “And why is there a routename AND a key” - this is because you can have multiple instances of a route (eg: in a stack you can push routes as many times as you like) and there needs to be a way to uniquely identify each one. you often don’t need to think about key and i’ve further reduced the need to do this in https://github.com/react-navigation/rfcs/blob/master/text/0004-less-pushy-navigate.md for 2.0. but in some cases you need low level control like that, and so key gives you it.
Can we not just use a directory-style path like Root/TabNav1/Screen1
what problem does this solve? if you use a unique routename then the full path doesn’t matter. not clear to me what this would look like either.
A PR was recently accepted added more layers by passing a key = null to perform some kind of secondary reset to the state
i don’t understand what you mean here. which pr is this?
Confusing API: If I want to return a navigator inside a general React class component,I need to mutate the router property, this seems like a workaround.
generally you should not need to do this. that said, we should make this more clear to people. we’ve been working on improving docs and this seems like a valuable point to make super clear! if this is your only concern re confusing api i think we’re doing quite well 
Redux integration is very unclear.
you shouldn’t use it. it’s super weird that so many people want to do this. why break the encapsulation of navigation state by integrating it into all of your other state? 2.0 almost entirely eliminates any reason you might want to use redux. also see https://github.com/react-navigation/rfcs/issues/14 and https://twitter.com/reactnavigation/status/968522317398601728. we should add a bigger note to docs indicating this.
Navigation debouncing should come out of the box, with not a line of additional code needed
this is largely handled in 2.0 via https://github.com/react-navigation/rfcs/blob/master/text/0004-less-pushy-navigate.md. the only case where this will still be relevant is if you explicitly use the “push” action, and we’ll explore options for improving that as well, but it’s actually more rare than you think.
bugs: I won’t even go through the whole list, but some include not being able to truly goBack() across tabs,
i don’t know what you mean about not being able to “truly goBack()” across tabs. can you explain?
navigation being dispatched multiple times if RouteNames on nested navigators not named a certain way.
i don’t understand this one either, can you explain or link to an issue?
