The issue seems to be out of TE-scope as it is related to bash script code. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

Mark WontFix since Chrome should change U+00A0 to U+0020 when putting into clipboard.

Note: U+00A0 comes from
"<code class="bash spaces">&nbsp;&nbsp;&nbsp;&nbsp;</code>"

Note: Windows OS converts U+00A0 to U+0020 for "text/plain" even if Chrome puts U+00A0 into clipboard. Windows OS keeps U+00A0 for "text/html".

So you're saying it works as intended?  I'm a bit confused.  When I copy that bash script in Chrome on Linux, it doesn't work the way it should when I execute the bash script. 

Sorry for confusion. I said from Chrome's point of view putting U+00A0 into clipboard is correct and expected. In other words, this is plug-in issue instead of Chrome.

Please ask plug-in author not to use U+00A0 to make indentation.
Once plug-in use "white-space: pre" style with U+0020, you can get U+0020 in clipboard, e.g.

<style>
...
.spaces { white-space: pre }
...
</style>

<code class="bash spaces">    </code>

Thanks, would you say this is a proper summary of the syntax highlighting script issue?

https://stackoverflow.com/questions/51794845/pre-html-nbsp-m-bm-bash-scripts-syntax-highlighting-on-the-web-remove-asc/#answer-52744644

It looks like Firefox converts   automatically.  Chrome should too?  There's a bug report with Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=359303) asking for it to not behave like that, but I'm going to argue that it should behave like this.

I posted a comment here:

https://bugzilla.mozilla.org/show_bug.cgi?id=359303#c44

I still think Chrome should also convert &nbsp; over to normal spaces when text is copied from a textarea or when text is copied from <code> elements.

Seems to be a locale language thing (as mentioned in the Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=359303), so I guess Chrome does handle this correctly.