In the Application module, I know compile_env is newer than get_env and fetch_env, but it seems like it would be helpful to have the same function signature that allows passing a “key_or_path” to all of these.

compile_env(app, key_or_path, default \\ nil)
get_env(app, key, default \\ nil)
fetch_env(app, key)

I’d like the ability to do this:
path = Application.fetch_env!(:device, [:connection, :polling_interval])
and have the run time checks related to compile_env catch it.

Here is why I’m thinking of this.
Note: I realize this is contrived, and you’d almost have to try to do it wrong to have this code. but still, why shouldn’t we make the functions have the same signature?

When I have a config, sometimes I want to make parts of it set at compile time, and other parts of the config dynamic (set at run time).

And without matching calls, it seems like you could hide the problem compile_env is trying to fix.
For example:

If you have this in one place:
@polling_interval Application.compile_env!(:backend, [:connection, :polling_interval])

Nothing prevents you from doing this in another place:

# In a config file like config/releases.exs 
custom_polling_interval = System.get_env("POLLING_INTERVAL")

config :backend, :connection,
  polling_interval: custom_polling_interval,

And then trying to do this (and getting a different value than the result from compile_env), which is what compile_env tries to help us avoid.

connection = Application.get_env(:device, :connection)
path = Keyword.fetch(connection, :polling_interval)

Maybe that will still get a runtime error, and my example is invalid.