Today CLI uses aesh 0.66.+. This branch is not going to evolve. aesh project is moving away from this branch. Legacy aesh 0.66.+ library is going to be split into 2 libraries:
1) aesh-realine 1.0, the foundations (terminal, character handling, history, user interaction such as Enter, TAB, Ctrl-C).
2) aesh 1.0, based on aesh-readline containing the console and the Command API.

It happens that CLI is using today only a subset of aesh 0.66.+. This subset is similar to what aesh-readline is offering. I say similar because aesh-readline is a complete rewrite.
So it makes sense, in order to follow aesh evolutions, to rewrite the CLI aesh integration and rely on aesh-readline.

The benefits are:

• Blocking API. No more active polling in CLI (used to be around 1% CPU activity). That will be 0.1%
• Less tricks in the CLI code to support prompting users (userName, password).
• Help aesh project to evolve the aesh-readline API (feature and quality). We are the main consumer of this API and we come with a bunch of usage contexts that reveal issues.
• aesh (The console and API), that we will use in CLI.next will benefit from any improvement we are doing today in aesh-readline.
• aesh-readline should consume less memory and be more reactive.

The risks:

• aesh-readline is mainly tested by the CLI integration. There are not (yet) intensive usage of aesh-readline. So we can expect some regressions (although 100% of unit tests will pass).