Advice to avoid simple transitive compile-time dependency

That’s a quite a few assumptions about the knowledge of the compiler. In this specific case the imported functionality is a guard, which indeed cannot depend on by_the_way due to limitations of guards. But it could also be a normal macro, which might call by_the_way at some point during execution.

Because compiler do not know (and in general sense it cannot know) that A do not depend on B.by_the_way. Phoenix generates module that is perfect example of that:

def module MyAppWeb do
  defmacro __using__(name) do
    apply(__MODULE__, name, [])
  end

  # …
end

This shows that calling macro can call any function within our module.

It can:

defmodule Foo do
  defguard is_foo(a) when foo(a)

  defmacro foo(a) do
    by_the_way()

    quote do: true
  end

  def by_the_way, do: C.something()
end

Good point. A macro could be part of the defguard and that macro can then call anything again.

defmodule Foo do
  defguard is_foo(a) when foo()

  defmacro foo() do
    if by_the_way() do
      quote do: true
    else
      quote do: false
    end
  end

  def by_the_way, do: C.something()
end

Elixir tracks dependencies at the module level. One common approach to address this is to define constants (which you may access at compile-time, such as invoice_states) and guards that are used across multiple modules into a separate module that only defines constants/guards (and does not call anything else).

Well, at least there is one thing that I do that is recommended by the core team.

Are “constants” in this context just functions that return a literal value?

Yes! Values that you would want to access in guards and patterns.

lol, ever on the eternal constants quest