(This is, of course, horribly broken in C++ which likes to inline everything.)
I would argue that both of these (or atleast the core of these) is addressed by Go.
For documentation, there is a simpler way to get at a library's public API; an automated program that extracts that API and presents it in a web page (or in your console). See http://golang.org/pkg/unicode/utf8/ for an example (for completeness, here is the file it is generated from http://golang.org/src/pkg/unicode/utf8/utf8.go)
For avoiding unnecessary recompiles, Go solves this problem by making compiles really fast, rendering this problem moot.
In the early 80s you could achieve Go like compile times in Modula-2 and Turbo Pascal, just to cite two examples.
With C becoming widespread we lost the better tooling offered by those languages, to be stuck in 70's like compiler tooling.
Luckily Go, D, Rust will eventually bring modules back to the system programming languages domain.
Even then, you might hit the issue that although the interface matches syntactical, the semantic meaning of the method calls differs.
For the CS folks, Go interfaces are nothing more than structural typing, available almost any FP language.
The only advantage over Java, C#, D is that you are not required to state explicitly which interfaces a given type implements.
However this forces you to use tools to discover which interfaces a given type implements.