First, Nickle is not a text-processing language. While it does include some rudimentary support for strings, and support for file I/O and formatting comparable to (and modeled after) UNIX stdio, it has no native support for such niceties as regular-expression-based pattern matching, implicit stream processing, textual variable substitutions, text editing, etc. While the authors have considered the problem of designing a modern text processing language, it would not look a great deal like Nickle; in addition, it is not clear that there is a niche for yet another text processing language given the popularity of many existing candidates.
Second, Nickle is not a language for building large applications. While it does have some support for syntax-level modularity, the implementation is currently rather dependent on whole-program compilation. In addition, the exclusion of OOP and GUI features, as well as the relative inefficiency of the current implementation, augers ill for Nickle's acceptance as a replacement for Ada.
Third, Nickle is not a symbolic algebra package. Its domain is strictly numeric. While a great deal of the Nickle feature set might be useful in a symbolic algebra package, constructing such a thing is probably beyond the purview of a two-person team inexperienced in such matters, and certainly would vastly exceed the current 25K lines of code.