It sounds to me like you want to teach your editor how to be 'smart' enough to recombine all of the included bits into one big makefile, or at least provide convenient access to the external stuff within the 'grand' makefile. Perhaps with logic to know what file to save which edit? Its a great dream!
For that, you'd have to check with the developers / vendor of your editor / IDE.
What I can say is, the only 'good' reason for breaking out various bits of business in separate included segments is conditional compilation. For instance, if you are using chunks of a diet C library to replace some of the stuff that the host system provides .. you'll want to include targets to do that based on the architecture and possibly OS distributor. That's when it makes sense to break it out .. let the ARM maintainers adjust their own targets and dependencies, just like the amd64 and ia32 folks would. When you do this and keep the logic that decides what to include in the central makefile, the logic is very easy to follow.
People who do it just to make the main Makefile appear smaller and easier to read are doing exactly what you say, making things more difficult in an effort to make something inherently inelegant appear elegant.
It frustrates me too, at times, even though I'm guilty of doing it in earlier projects :)