Implicit compile-time dependencies

I understand what runtime and compile dependencies between modules are and when they happen. But I have a problem understanding one particular situation in which a recompilation of some files is required after changes in others.

Here’s what xref graph shows:

~/dev/elixir/dep-example $ elixir --version
Erlang/OTP 21 [erts-10.2] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]

Elixir 1.10.0 (compiled with Erlang/OTP 21)
~/dev/elixir/dep-example $ mix xref graph
lib/a.ex
└── lib/b.ex (compile)
    └── lib/c.ex
lib/b.ex
lib/c.ex

There’s only only one compile dependency: A depends on B at compile-time.
However when C changes, it causes recompilation of A.

~/dev/elixir/dep-example $ touch lib/c.ex
~/dev/elixir/dep-example $ mix compile --verbose
Compiling 2 files (.ex)
Compiled lib/c.ex
Compiled lib/a.ex

The compiler works like this: it walks through a list of modules, checks dependencies between them and determines what has changed and what needs to be recompiled in the consequence of the changes.

The process in above situation is as follows:

1. compiler detects that C changed (on disk), marks it as stale and for recompilation
2. compiler sees that B depends on something stale (C), so marks it as stale as well, but doesn’t mark it for recompilation because it’s only runtime dependency
3. compiler sees that A depends on something stale (B), marks it as stale, but this time it’s a compile dependency, so the file is marked for recompilation too.

In the end, both A and C are recompiled, B is left intact.

Clearly A has an implicit compile dependency on C.

What’s the reasoning for that?

I cannot think of any scenario (usage of imports, macros, etc) when lack of recompilation of A in this situation would cause bugs. Can you help me find some examples?