Say you have a library crate that uses log for "production logging" and tracing for "dev logs", and this crate takes "ownership" of log and tracing (it is responsible for initializing them).
The log level can be controlled via the environment variable LOG_LEVEL and the tracing "level" is set using TRACE_LEVEL.
The end (application) user should basically never use TRACE_LEVEL -- in fact, they would normally never know about it. Only if the developer instructs them to enable it to track down a specific problem should they ever find out it even exists.
Let's say one would want to change the name of the environment variable from TRACE_LEVEL to TRACE_FILTER. Would this be considered a breaking change?
My argument for why it wouldn't: It would not cause any build problems. There's no API change. It's a runtime environment variable change. Had it been the LOG_LEVEL, then I could argue that it's a breaking change, because it could mean that customers may lose production logging after an upgrade. However, the TRACE_LEVEL/TRACE_FILTER is intended as an developer tool -- more or less an "internal" tool.
The counter-argument would be that it's important for downstream developers to find out about these types of changes as well. Treating it as a breaking change would make it more likely that they check the changelog and notice the change.