Re "nano" with LTR vs. autodetected directionality:
The LTR screenshot is more obviously "broken" (or at least undesireable). The autodetected directionality's brokenness is less obvious, maybe no breakage is visible in this particular screenshot, but is still broken.
Maybe it looks pretty much okay with fully RTL text. But try to edit some BiDi text where the text sporadically contains some English words, or numbers. Scroll the long lines horizontally, so that these words and numbers just scroll in or out, or just cross the terminal's edge. You'll see it breaking here and there. Combine it further with nano showing the line numbers (Alt-N), I expect more breakages. Edit some file that contains pairs of ( ) or < > characters, you'll see that the way they are mirrored or not is occasionally broken, and (I think although I haven't tried) even nano's reverse video < > signs at the margin that denote that the line continues might join this game in faulty ways.
In my BiDi proposal, in the section "Why terminals are a truly special story" I argue that fullscreen text viewers/editors (such as nano, vi, emacs, mcedit, joe...) only send partial information to the terminal (only parts of the entire text) and it's impossible to run the BiDi algorithm on partial data. I prove that it's literally impossible to achieve proper BiDi text editing user experience if performing BiDi is the job of the terminal emulators. Hence, in accordance with ECMA TR/53, in such cases it has to be the application (e.g. nano) that runs the BiDi algorithm and the terminal must not shuffle the characters. The terminal can be programatically switched to this so-called "explicit mode" using the BDSM escape sequence.
The only way to have a proper BiDi-editing experience in nano is if nano adds BiDi support, meaning that on one hand it runs the Unicode Bidirectcional Algorithm [UBA] itself, on the other hand it asks the terminal not to do that.
In "implicit mode", where the terminal runs the UBA, even if combined with automatic detection of paragraph direction and alignment, if you try to have the typical text editing user experience then there will be numberous fundamentally unfixable bugs. The only way to fix them is to use the terminal's "explicit mode" instead.
The single most important bit from my BiDi work is (reinforcing ECMA TR/53's realization) that it's either the terminal (and not the application) or the application (and not the terminal) that needs to perform the UBA, and that both of these modes are required (for some utilities like "apt" only the "impicit mode" is reasonably viable, for some other apps like "nano" only the "explicit mode" is usable), and that it has to be programatically switchable. Prior to this work from me (both the spec and the implementation in VTE) all the terminals I'm aware of either only implemented "this" mode (making it impossible to run BiDi apps that required "that" mode), or only implemented "that" mode (making it impossible to run BiDi apps that required "this" mode), or asked the user to choose the behavior (an utterly unacceptable user experience to have to manually switch back and forth, let alone so extremely frequently), and due to this utterly messy situation application developers had absolutely no clue how they needed to send RTL text to the terminal.
Whether autodetection is enabled or disabled is a property within the "implicit mode", in "explicit mode" this setting plays no role.
The only way to have proper BiDi support in nano is to go ahead and implement BiDi support in nano, relying on the terminal's "explicit mode". There's no way the terminal could do it on its own, without nano's help. It's substantially different from let's say "apt" or "ls" because those utilities tell the entire text to the terminal (therefore the terminal can run UBA), whereas nano by its very nature only sends partial text to the terminal (therefore the terminal has no chance whatsoever to property figure out the rest and do the BiDi shuffling).
Therefore, the argument that autodetection should be enabled for the sake of a better (but still quite broken) BiDi experience in nano (using the terminal's "implicit mode") is completely invalid.
Re "nano" with LTR vs. autodetected directionality:
The LTR screenshot is more obviously "broken" (or at least undesireable). The autodetected directionality's brokenness is less obvious, maybe no breakage is visible in this particular screenshot, but is still broken.
Maybe it looks pretty much okay with fully RTL text. But try to edit some BiDi text where the text sporadically contains some English words, or numbers. Scroll the long lines horizontally, so that these words and numbers just scroll in or out, or just cross the terminal's edge. You'll see it breaking here and there. Combine it further with nano showing the line numbers (Alt-N), I expect more breakages. Edit some file that contains pairs of ( ) or < > characters, you'll see that the way they are mirrored or not is occasionally broken, and (I think although I haven't tried) even nano's reverse video < > signs at the margin that denote that the line continues might join this game in faulty ways.
In my BiDi proposal, in the section "Why terminals are a truly special story" I argue that fullscreen text viewers/editors (such as nano, vi, emacs, mcedit, joe...) only send partial information to the terminal (only parts of the entire text) and it's impossible to run the BiDi algorithm on partial data. I prove that it's literally impossible to achieve proper BiDi text editing user experience if performing BiDi is the job of the terminal emulators. Hence, in accordance with ECMA TR/53, in such cases it has to be the application (e.g. nano) that runs the BiDi algorithm and the terminal must not shuffle the characters. The terminal can be programatically switched to this so-called "explicit mode" using the BDSM escape sequence.
The only way to have a proper BiDi-editing experience in nano is if nano adds BiDi support, meaning that on one hand it runs the Unicode Bidirectcional Algorithm [UBA] itself, on the other hand it asks the terminal not to do that.
In "implicit mode", where the terminal runs the UBA, even if combined with automatic detection of paragraph direction and alignment, if you try to have the typical text editing user experience then there will be numberous fundamentally unfixable bugs. The only way to fix them is to use the terminal's "explicit mode" instead.
The single most important bit from my BiDi work is (reinforcing ECMA TR/53's realization) that it's either the terminal (and not the application) or the application (and not the terminal) that needs to perform the UBA, and that both of these modes are required (for some utilities like "apt" only the "impicit mode" is reasonably viable, for some other apps like "nano" only the "explicit mode" is usable), and that it has to be programatically switchable. Prior to this work from me (both the spec and the implementation in VTE) all the terminals I'm aware of either only implemented "this" mode (making it impossible to run BiDi apps that required "that" mode), or only implemented "that" mode (making it impossible to run BiDi apps that required "this" mode), or asked the user to choose the behavior (an utterly unacceptable user experience to have to manually switch back and forth, let alone so extremely frequently), and due to this utterly messy situation application developers had absolutely no clue how they needed to send RTL text to the terminal.
Whether autodetection is enabled or disabled is a property within the "implicit mode", in "explicit mode" this setting plays no role.
The only way to have proper BiDi support in nano is to go ahead and implement BiDi support in nano, relying on the terminal's "explicit mode". There's no way the terminal could do it on its own, without nano's help. It's substantially different from let's say "apt" or "ls" because those utilities tell the entire text to the terminal (therefore the terminal can run UBA), whereas nano by its very nature only sends partial text to the terminal (therefore the terminal has no chance whatsoever to property figure out the rest and do the BiDi shuffling).
Therefore, the argument that autodetection should be enabled for the sake of a better (but still quite broken) BiDi experience in nano (using the terminal's "implicit mode") is completely invalid.