Freestanding macro with attached macro can't find code inside attached macro

I discovered a bug while attempting to use a freestanding macro with an attached macro inside. The compiler can't seem to reference code inside the attached macro while inside the freestanding macro. Here's a link to a project with a simple example: https://github.com/jonduenas/ProEntitlementStreamTest/blob/main/ProEntitlementStreamTest/ContentView.swift

I'm utilizing PointFree's swift-dependencies library and their @DependencyClient macro on a struct. It adds a basic init inside the struct (among other things). I then try to access this init inside a SwiftUI #Preview macro, but get the error message saying the struct cannot be constructed because it has no accessible initializers. If I try to call the init outside the #Preview macro, it works fine. Here's the core of it copied from the project linked above...

@DependencyClient
public struct ProEntitlementStream {
    public var entitlement: () -> AsyncStream<Bool> = { .never }
}

// The above expands to this:
public struct ProEntitlementStream {
    public var entitlement: () -> AsyncStream<Bool> = { .never }
    public init(
        entitlement: @escaping () -> AsyncStream<Bool>
    ) {
        self.entitlement = entitlement
    }

    public init() {
    }
}

// Trying to use the macro inside #Preview
#Preview {
    ContentView(
        model: Model(
            proStream: ProEntitlementStream(entitlement: { // Error here: 'ProEntitlementStream' cannot be constructed because it has no accessible initializers
                AsyncStream<Bool>.never
            }
        )
    ))
}

Having exactly the same issue. The only work around I have found, other than falling back to Preview Providers, is to use a wrapper view.

e.g.

struct Wrapper: View { 
  var body: some View {
    ContentView(
        model: Model(
            proStream: ProEntitlementStream(entitlement: { 
                AsyncStream<Bool>.never
            }
        )
    ))
  }
}

#Preview { 
  Wrapper()
}

Were you ever able to find a solution here?

No solution that I know of other than the two you mentioned. I think this is just how macros work? But, I don't know enough and haven't tried to find any other solution myself.

None yet. Sorry

This is a pretty massive limitation in the current implementation of macros, and I haven’t found a way around it either.

I think fixing this is likely going to require a fundamental change in how macros are expanded and compiled