Transitive export of inner type via public typealias warning

I have 3 frameworks (I've tested this with 3 SPM library packages, the compiler emits the same warning).

In framework "C", I've defined a struct in a public file:

public struct StructFromC {
    public struct Inner {
        public init() {}
    }
    public init() {}
}

In framework "B", I have a public file containing the following:

import FrameworkC
public typealias StructFromCViaB = FrameworkC.StructFromC

In framework "A", I have a file containing the following:

import FrameworkB
// No warnings
let structC = StructFromCViaB()
// No warnings
let inner = StructFromCViaB.Inner()
// No warnings
public let publicStructC = StructFromCViaB()
// Warning: Cannot use struct 'Inner' here; 'FrameworkC' was not imported by this file
public let publicInner = StructFromCViaB.Inner()

Prior to Xcode 14.3 (or was it Xcode 14.2?), the warning above was not emitted by the compiler. As of Xcode 15, the warning is still emitted. I'm surprised I can declare "public let publicStructC" without a warning, but declaring "public let publicInner" produces a warning.

Is this warning spurious and thus a compiler bug?
Or was this design flawed and will it eventually fail to compile?

Thanks,
--David

I've attached sample projects to Feedback: FB12389427

Do the libraries have library evolution enabled? This diagnostic was implemented to prevent the compiler from emitting unparseable .swiftinterfaces. When the compiler prints a module interface, it may desugar any reference to a typealias. If the typealias references an original type that is declared in another library, then the desugared type can't be referenced directly unless the module that defines it is explicitly imported. So the diagnostic encourages you to ensure that your module publicly imports the necessary modules.

This is very helpful.

No, library evolution is not enabled. The application is highly modularized (~46 frameworks plus the main app), however, it is built as a monolith.