ReactN is absolutely and deliberately tied to React — hence the name. If you want to change frameworks, you’ll lose it. It openly targets small and personal projects, not large or enterprise applications.
ReactN is not an attack on flux architecture. Flux has its merits, and I absolutely support it, Redux, and the solutions that they provide to very real world global state management problems. ReactN does not attempt to solve these problems or provide these functionalities in the same way that local component state does not attempt to solve them either.
ReactN is certainly not comparable to a global variable. ReactN is a React-first solution to global state management. It is deliberately hard coupled to React for an intuitive and boilerplate-free implementation of global state that revolves around React’s functionality and core concepts, such as component updating and hooks.
If your project intends to “survive React,” is large enough to benefit from flux architecture, or benefits from Redux’s extended functionality, I completely agree with you that ReactN does not suit your needs. It does not try to meet those needs, and that’s okay. What it does try to do, however, is save time and result in more maintainable code on projects that do not have these requirements. I think it does that well.
Every project will be different as to whether it’s worth trading functionality for intuitive code. ReactN is not a solution for every project. It is a solution for the vocal community of developers who don’t believe Redux’s implementation is worth the boilerplate required. This feedback most often spawns from smaller projects and junior developers. That is the only target audience. Many applications would benefit from Redux; however, many would benefit from ReactN instead.