@inlinable doesn't make any such guarantees, unless the library offers ABI stability (i.e. system libraries). For your regular Swift package, cross-module inlining has basically no downside, except perhaps increased compile time.
Anyway, I feel the whole point about compiler-evaluable functions is diverging from the point of this pitch: that you sometimes need to ensure that a particular value or function parameter is known at compile time.
One example is memory ordering parameters used by swift-atomics. This currently requires special @_semantics attributes, and is another example of important libraries being released with underscored language features.
Perhaps @lorentey can correct me if I'm wrong, but I believe the feature pitched here would be sufficient for them to drop that particular attribute. That alone would be a big win IMO.