I am strongly +1 this change but I think it should be proposed as an overall "internal documentation" feature rather than this one change. Alternatively, so that we can make incremental forward progress, I would support exposing this as an experimental flag. I think there are challenges that need to be solved in UI and authoring before this is possible.
For example, symbol paths become more complicated (for authoring and for page urls) because you can now introduce conflicts. Suppose you define the following function, and you copy-paste it into two different files (or you just happen to create a function with the same name):
fileprivate func printInt(_ x: Int) { print(x) }
Following the existing DocC URL rules, the url for this type would be MyModule/printInt however because the function was defined in two files, you'd have two pages with the same url. There are straightforward solutions to these problems—for example, you could add the file name into the path somewhere, or use the symbol identifier hash suffix—but they need to be enumerated and addressed.
Another issue that needs resolving is around authoring documentation that may be built at different access levels. For example, suppose I want to build documentation including in the internal access level for my team, and I also want to build documentation at the public access level for framework clients. How do we handle links in prose and in groups that only resolve under the internal access level? Do we need special handling for diagnostics, or a way to omit them with some sort of @AccessControl(internal) { ... prose ... } directive? What about sentences, paragraphs, assets, or even entire files that should only appear in the internal docs?