Broadly, +0.5.
I remain convinced by arguments from the pitch thread that the 'bare' /.../ syntax is not obviously worth the breakage, and I see no real reason why it needs to be included in this proposal. In the interest of more conservative evolution that is informed by usage, I'd prefer to see this proposal tackle the #/.../# syntax to bring regex literals into the language, and a later proposal address the question of "do we need a more terse syntax?" once the community has had broader experience with the base feature.
As it stands, the bare syntax won't be available by default until Swift 6 which is an unknown number of months (years?) away, so I don't think there's a huge amount of functional difference between splitting this into two proposals, one of which could be evaluated closer to Swift-6-time. However, I think it does make a difference process-wise. IMO combining both syntaxes into this proposal muddies the evolution process and makes it more difficult for the community to evaluate each aspect individually.
My subjective impression from the pitch thread is that there's overwhelming support for the #/.../# syntax, but much more apprehension about the /.../ syntax. I'd hate for us to get caught up in the excitement of introducing regex literals to the language (which is very exciting!) and adopt a syntax which does not pull its weight compared to the difficult-to-quantify impact of a source break in terms of developer effort and harm to goodwill.