Part 1
Having dedicated literal: +1. I already stated my support for the goal of having regex literals in Swift source code that provide compile-time checks and typed-capture inference.
Part 2
Choice of delimiter. I think the magic literal alternative is not adequately considered. The idea of replacing the internal delimiter with another character, specifically /, is not adequately considered. The only justification provided is that we have not done this before. Are there any other down sides to it besides it being novel?
The advantage of #regex/.../ is that for the contents of the literal it has exactly the same behavior as if the literal was /.../. It does also score in familiarity, as it is already the same literal as say Perl, with a prefix. The other advantage is opening the door for normalizing this type of syntax for other compile-time checked and potentially library-based new types of literals (like property wrappers). We should be able to be flexible about the specific delimiter used after the #whatever and if we support library defined custom literals, we could let the library specify the supported delimiters. For example, both #sql"...." and #sql'...'. We should also be able to easily extend it to support multi-line variants.
The down sides that I see are being novel and its verbosity.
I don't see the first one (bringing something new to the language) as inherently bad, unless there is a clearly better alternative within the current norms, which I don't see any. Please correct me if I am wrong on this.
The verbosity: this is more subjective and depends on people's preferences, uses and experiences. This can be mostly addressed by privileging regexes as the most common case of such delimiters as being allowed to use #/.../ (as opposed to shortened magic literal) in addition to the already proposed #/.../#.
I also think we could explore using single quotes without completely sacrificing it to this use case a bit deeper. For example, we could ask '/' and '//' literals written as ''/' and ''//' to enable using '/.../' to achieve minimal noise and keep single quote still usable for uses like ASCII literal (e.g. 'A') and source compatibility. I know ''/' and ''//' would be special cases, but they would come after '/.../' is established. We could even reserve the whole starting with a delimiter case to support other literal types with other delimiters (e.g. '!...!').