README: Explain the runtime consistency check

README.md

@@ -538,6 +538,8 @@ let%track_sexp nonempty () : int =
 let () = print_endline @@ Int.to_string @@ nonempty ()
 ```
 
+This will not emit logging code that is above the stated log level. Note that the compile-time pruning of logging happens independently of the runtime log level! This gives more flexibility but can lead to confusing situations.
+
 There's also a way to compile the code adaptively, using a shell environment variable: `[%%global_debug_log_level_from_env_var "environment_variable_name"]`. The variable name is case-sensitive, but the values are case-insensitive. The recognized values of the environment variables are:
 
 - `nothing`: translates to `Nothing`
@@ -549,7 +551,7 @@ There's also a way to compile the code adaptively, using a shell environment var
 - `everything`: translates to `Everything`
 - `` (empty): no change
 
-**BEWARE**: using `%%global_debug_log_level_from_env_var` is very prone to workflow bugs where different parts of a codebase are compiled with different log levels, leading to very confusing behavior.
+The generated code will check that the compile-time adaptive pruning matches the runtime value of the environment variable. If that's an obstacle, use `%%global_debug_log_level_from_env_var_unsafe` which will not perform the check. Using `%%global_debug_log_level_from_env_var_unsafe` is very prone to workflow bugs where different parts of a codebase are compiled with different log levels, leading to confusing behavior.
 
 With some "abuse of notation", we use `Prefixed [||]` resp. `Prefixed_or_result [||]` to mean all-and-only explicit logs (resp. also result logs). `Prefixed [||]` only works at compile time. `Prefixed_or_result [||]` works as intended when set both at compile time and at runtime: then, it will output all explicit logs, but also results in otherwise-nonempty entries. Example from the test suite:
 

index.mld

@@ -544,6 +544,8 @@ let%track_sexp nonempty () : int =
 let () = print_endline @@ Int.to_string @@ nonempty ()
 ]}
 
+This will not emit logging code that is above the stated log level. Note that the compile-time pruning of logging happens independently of the runtime log level! This gives more flexibility but can lead to confusing situations.
+
 There's also a way to compile the code adaptively, using a shell environment variable: [[%%global_debug_log_level_from_env_var "environment_variable_name"]]. The variable name is case-sensitive, but the values are case-insensitive. The recognized values of the environment variables are:
 {ul {- [nothing]: translates to [Nothing]
 }{- [prefixed_error]: translates to [Prefixed [| "ERROR" |]]
@@ -555,7 +557,7 @@ There's also a way to compile the code adaptively, using a shell environment var
 }{- `` (empty): no change
 }}
 
-{b BEWARE}: using [%%global_debug_log_level_from_env_var] is very prone to workflow bugs where different parts of a codebase are compiled with different log levels, leading to very confusing behavior.
+The generated code will check that the compile-time adaptive pruning matches the runtime value of the environment variable. If that's an obstacle, use [%%global_debug_log_level_from_env_var_unsafe] which will not perform the check. Using [%%global_debug_log_level_from_env_var_unsafe] is very prone to workflow bugs where different parts of a codebase are compiled with different log levels, leading to confusing behavior.
 
 With some "abuse of notation", we use [Prefixed [||]] resp. [Prefixed_or_result [||]] to mean all-and-only explicit logs (resp. also result logs). [Prefixed [||]] only works at compile time. [Prefixed_or_result [||]] works as intended when set both at compile time and at runtime: then, it will output all explicit logs, but also results in otherwise-nonempty entries. Example from the test suite: