Much better, thanks.
Specifically, WRT ...

1. Nice.

2. Sorry, that was a misunderstanding: I merely meant to *suggest* either discarding or substituting forbidden characters. As my own hostnames only contain [a-z], your Patch was doing what I wanted starting with its first version. Still I am glad you added the hostnamectl method, and plan to completely switch to it, when SFOS 2.1.1-final is released.
Yes, you are absolutely right, that substituting some forbidden characters (e.g. space " " and underscore "_" with a hyphen "-"), while simply removing others (all other special characters and all hyphens "-" at the start of the hostname string) is even nicer. But there is a point at which one has to stop such considerations, as the next logical step would be to think about substituting "ç" with "c", "Ç"-->"C", [őøöôòó]-->"o", and so on. I would have stopped one step earlier and chosen either "always substitute" or "always remove". But hey, this Patch is "your baby", so I can only suggest what I believe is best for the average user, and it is up to you what you decide for and finally implement. Stating "Won't fix" / " Won't implement that" is also always a possible option as a Free Software coder, as we are all doing this voluntarily, and primarily to satisfy our own needs.

But I actually think you should better *not* provide the user with an option to switch off the filtering: Just choose a filter scheme, which is *always* applied when hitting the "Apply" button. Then the string "Name without special characters" could be removed, also.

3. I believe the character set for hostnames is still (classic 7-bit) ASCII, at least on the network side. I don't know what a modern shell as bash uses for its environment variables and shell prompt, but busybox is likely to use extended (8-bit) ASCII. Mmh, if you really want to be sure about this, I can try to clarify the situation for SFOS 2 (just let me know), but ...
a. All allowed characters ([a-z, A-Z, 0-9,-]) are within the 7-bit ASCII range, so they will be encoded to a single byte in ASCII encoding and variable length Unicode encodings.
b. If something (e.g. a shell or systemd) uses UCS-2 encoding, every character is encoded in two bytes.
x. Other Unicode encodings (than UCS-2 and variable length encodings) are not practically relevant, IMO.
Note that, while the quick answer is "hostname has to consist of 1 to 63 (not 64!) ASCII characters" (see e.g. https://technet.microsoft.com/en-us/library/cc959867.aspx), this answer has become much more complicated (see e.g. https://stackoverflow.com/a/28918017 for a concise *and* additionally a detailed answer). In short, the network hostname should be at most between 19 and 31 characters long, depending on the use case, but must be at least one character long.

So when taking all this into account, I suggest limiting the input in the hostname field to 31 characters to be on the safe side for network name and shell prompt.

4. Testing v0.0.1-5 with filtering on.
a. Input (again): +-My.Hostname=666,1-3;Üç#(me@here?)!
- Classic method: --> MyHostname6661-3Üçmehere
Not O.K., e.g. "Ü" and "ç" are not removed.
- hostnamectl method: --> myhostname6661-3mehere
O.K., works nicely.
b. Empty input string: Notification "Nothing to change!". Very good!
c. Played with some strings containing only spaces " " and hyphens "-", plus some strings as "- +_":
- Empty hostname (forbidden) set with classic method: Not O.K.!
- Hostname set to "resetname" with hostnamectl method: O.K. and nice.
I have not looked at the code, but you seem to use a different filtering for the classic and the hostnamectl method. The filtering for the hostnamectl method seems to work well, while the filtering for the classic method is buggy. Wouldn't it be easier to filter the input string first (with a single filtering scheme / code section), and then converting to lowercase for the hostnamectl method?

HTH & best regards.