Surfaces look an awful lot like a subset of the custom availability domain concept I pitched a while back. As far as I can tell, the main difference is that grants for surfaces are purely syntactic ceremony because they always succeed, whereas an if #available check may evaluate to false at either runtime or compile time for a certain domain, making code protected by that domain unreachable.
API partitioning purely for the sake of documenting intended audiences was not a use case I had in mind when developing custom availability domains, but there wouldn't be anything stopping someone from using it that way. You could declare an availability domain that is always available at compile time and decorate APIs with it to require availability to be checked prior to using those APIs. Availability is a more powerful tool, though, because it allows you to express API partitioning requirements that can have a meaningful effect on abstract program execution. For example, you could declare a Testing availability domain that is either available or unavailable at compile time. As long as the module is built in a testing configuration, the APIs annotated @available(Testing) are present and available to be executed at runtime. But in release builds the Testing domain can be configured to be unavailable at compile time, allowing the compiler to perform a guaranteed optimization that strips all code from the final binary that is only reachable when Testing is enabled. A Testing surface, on the other hand, has no effect on how the program is compiled so developers would have to take additional measures to remove code annotated with the surface[Testing] from released binaries.
I'm actively working on the implementation of this availability domains pitch. If you want to experiment with it everything but a syntax for declaring availability domains in Swift code is already implemented behind the CustomAvailability experimental feature flag in the 6.4 toolchains. In the coming weeks I'm planning to post an updated pitch as well.