Unless doing some very specific text processing on the values, if just copied around verbatim, UTF-8 should not break anything compared to pure ASCII. BOM tools choking on UTF-8 should be burnt. But in particular if done with something as high-level as Python, not handling UTF-8 properly is just unexcusable.
But of course, one has to get some perspective. If we are talking about recent software, this is unexcusable, but if we are talking about software that is over 10-year old, that may be another story.
Not only that, there is a CVE associated with UTF-8 due to RTL recoding such that a load of application then had to flag when such char are used as they could be used to start (well end) some malicious intent
@naib, @Maverick17, and others: If you use UTF-8, you may run into problems. I raised a similar issue for KiCAD4, six years ago, because it converted UTF-8 in net names to question marks in the IPC-D-356 netlist. If you read that thread, one of the developers said that was explicitly the intended behavior. I don’t think that has changed.
Also for completeness: on macOS the Character Viewer is invoked using Fn+E or the menu Edit->Emoji & Symbols in most text entry areas. The Character Viewer lets you save favorite symbols for quick access.
Python 2 is now unsupported and Python 3 supports Unicode so I would suggest μ etc are no big deal in practice.
Incidentally, on Windows 11, I typed that Greek mi with Windows key + space, which switched me from US to Greek keyboard (which I happen to have installed, for other reasons). But there are other ways, like copy and paste from the character picker.