https://github.com/apple/swift-log/releases/tag/1.13.0 implemented the SLG-0004: metadata value attributes. Among the changes, extension Logger.MetadataValue: ExpressibleByStringInterpolation instead of the default automatic protocol implementation declaring associatedtype StringInterpolation : StringInterpolationProtocol = DefaultStringInterpolation where Self.StringLiteralType == Self.StringInterpolation.StringLiteralType, now declares a custom public struct StringInterpolation: StringInterpolationProtocol, Sendable. As the result, extensions for String.StringInterpolation cannot be directly used to create metadata values. This change was introduced to support attribute-specific string interpolations, enabling syntax: "key": "\(value, myCustomAttribute: .customAttributeValueA)".

Consider this example, which does compile with swift-log 1.12 and no longer compiles with swift-log 1.13:

extension String.StringInterpolation {
    fileprivate mutating func appendInterpolation(myCustomInterpolation value: Int) {
        self.appendLiteral("Int=\(value)")
    }
}

...

logger.info("Log message", metadata: [
    "key": "\(myCustomInterpolation: 42)"  // error: No exact matches in call to instance method 'info'
])

There are several workarounds:

1. Instead of declaring extension on String.StringInterpolation, declare it on extension StringInterpolationProtocol where StringLiteralType == String.
2. Instead of declaring extension on String.StringInterpolation, declare it on Logger.MetadataValue.StringInterpolation.
3. Wrap String interpolation inside MetadataValue interpolation with an extra layer: "key": "\("\(myCustomInterpolation: 42)")".
4. Explicitly construct a MetadataValue with a String: "key": .string("\(myCustomInterpolation: 42)").

While this is a clear SemVer break, the use-case is niche. The workarounds above each preserve the original call-site syntax with minimal change, so adopters who do hit this can migrate without restructuring code.

If you are affected by this change, please comment on this issue, so we can gauge real-world impact and decide whether to revert the custom StringInterpolation in a follow-up release.