In my mind, it will have to attract a strong enough community to survive without Microsoft's financial support which will probably shut down in a year or two. It's interesting because if it does hit critical mass that increases the likelihood that it will continue to be funded.
In the NodeJS world, sometimes "long-term" means 9 months it feels like. In open source, sometimes "support" means "file a PR if you care so much about that bug" or "fork it yourself". Are you perhaps expecting a longer term or more support because it is Microsoft behind it?
It looks actively maintained right now, but its published semver is 0.x. There are a lot of 0.x libraries in active use in NodeJS, but it's still semver-obvious grain of salt from the maintainers to keep in mind when considering it for support.
The README tells us that it was directly built to support a production need in Bing today. That seems like as big of a vote of support confidence as you might get from an open source project that a team has vested interest in it.
On the other hand, Bing isn't inside Microsoft's developer division, so they have fewer vested interests in supporting outside developers long term. It's also possible that at some point in the future they get internally sold on a developer division or Windows division or Azure alternative that Microsoft has financial or marketing reasons to commercialize.
If I had a production need for something like Napa.js I don't see any particular red flags to avoid it, it looks like it should be easy enough to migrate to something else down the road if necessary, and would probably consider it.
Microsoft Open Technologies had some successes here too: off the top of my head NodeJS and Git both have gotten much better on Windows as a result of work that Microsoft Open Technologies started in forks and eventually got merged upstream. The NAPI work to support both V8 and ChakraCore continues at a reasonable pace precisely because there is upstream engagement, upstream merging, and NodeJS-ChakraCore is less of a full fork more like a distro-specific build flag.
Plus, the priority on things like Redis for Windows shifted with the Windows Subsystem for Linux; there was less need to get open source projects to treat Windows as a supported distro directly when Windows can piggy back off of Ubuntu (or SUSE or Fedora) distro work.
None of that solves lack of communication about the forks left on the vine, and it is a shame there isn't strong redis support on Windows, but everyone has priorities, including antirez, and even if those priorities aren't communicated fully, they seem to at least be somewhat transparent to this humble developer from the outside of either work.