Think about two different scenarios.
A library/subsystem creator who has defined a lot of structures that need a specific order is the responsible that wants to make the usage, and thus the inclusion of headers, as easy as possible. This is why you find system header include statements in other include files. This makes the usage for the library function as easy as possible.
System-Header files are enclosed in <>.
The developer of a system/subsystem does not include his own header files from within header files, to have a better control about what is included within a single source files. Circular includes or other problems with undefined or double defined structures/defines and the like can be overcome if the application includes are only put into the source.
Application specific header files are enclosed in "".
Using <> or "" has todo with the search order of the pre-processor for include files.
Another thing is that pre-processor and compiler are two different things. The pre-processor creates a stream of text that results of processing any #directive. The compiler processes that stream after that processing has done. You can tell the compiler to only make the pre-processing step an put the result into a file/stdout. This way you can investigate the the order of files that are included and what the result of the pre-processing is.
Think of a define you made different to some system header file. You will not find the bug without have a look on the input stream to the compiler.
This is very interesting i really didn't know what was behind the compiling process, can you recommend a couple of books about this kind of topics?
