I think the issue is the ambiguity of this impl in the standard library: Option as From<T>
Moving the into() function to the caller allows you to add it only when needed. Updated playground
And even with this change, the final None value needs the turbofish syntax to specify which type of None::<T> it is.
Edit: I originally thought it'd be a confusion on some Option<U> as From<Option<T>> where U: From<T> impl, but I couldn't find that conversion on the docs.
A custom trait with no blanket implementations works for at least the four cases you've presented... except as @danjl1100 stated, when you pass in None, because there's no way for the compiler to know if you meant None::<String> or None::<&str> (and it can't assume it doesn't matter).
If you're set on doing this with a single entry point, and if you're willing to give up all Option cases except Option<String> (or whatever your ultimate value type is), you could support multiple bare values but only Option<String>. Then None will be unambiguous. This will be less ergonomic if someone has ahold of an Option<&str> they're trying to pass in, but for programmers just typing in values, they're going to just pass "literal" and not Some("literal") anyway.
(Or you could support only Option<&str> instead if that matches your use-case better, but that introduces the potential for unnecessary cloning. Though TBH it's probably not at all an actual problem for a builder. )