Here is my line of thinking on the addition of a new lowercased String function, vs adding two new static functions or a converting initializer.
I tend to avoid deprecating API just for naming reasons. My opinion is that this creates "deprecation fatigue," where developers start to ignore warnings because they feel somewhat arbitrary. For example, if you have code which today uses uuidString, doesn't care about the case, and has no need for the new API - why would you need to switch to a new API? I prefer to leave deprecation for cases where something is actively harmful and we really do need people to move off it.
For similar reasons, we cannot change the behavior of the existing method. There exists plenty of code out there that would break if we change the result of the uuidString to be lowercased. (For those that may not be aware, this change will be present not just in the Foundation package but also on every Apple OS that ships Swift 6.4, in the shared Foundation library that exists there).
And finally, given that we have an existing method, we should give the new one a name that is nearby, for discoverability in autocomplete, documentation, etc.