Retire the unprefixed env aliases (VERBOSE, COVERAGE, PARALLEL_RUN, …)

[Chemaclass]

Every setting in src/env.sh resolves as:

: "${BASHUNIT_X:=${X:=$_BASHUNIT_DEFAULT_X}}"

so roughly 36 bare names still configure bashunit: DEFAULT_PATH, VERBOSE, COVERAGE, PROFILE, STRICT_MODE, SIMPLE_OUTPUT, PARALLEL_RUN, TEST_TIMEOUT, and more.

The BASHUNIT_ prefix landed in 0.15.0 (~23 months ago). .env.example documents only the prefixed names; so does docs/configuration.md. The bare forms are undocumented back-compat.

This is an active hazard, not just cruft. The := form assigns the bare name as a side effect, and the names are extremely generic — a CI job that exports VERBOSE=true or COVERAGE=true for an unrelated tool silently reconfigures bashunit.

The codebase already agrees the pattern is wrong: src/env.sh documents exactly this reasoning as the justification for not adding bare aliases for RETRY, RANDOM_ORDER, SEED and SHARD_*. It simply hasn't retired the existing ones.

Precedent for breaking here exists (the 0.29.0 namespace break, the 0.30.0 --preserve-env rename).

Suggested path: emit a deprecation warning when a bare name is what supplied the value, for one minor; then drop them.

Found during the #862 audit; left alone there because it is a breaking change and the maintainer's call.

[Chemaclass]

Some measurements to size this up.

43 aliases, not the ~36 first estimated (grep -oE ':= *\$\{[A-Z_]+:=' src/env.sh).

Zero of them are used in the repo's own tests, workflows, or Makefile — so retiring them breaks nothing internally. The only occurrences anywhere are two documentation examples, and they illustrate the problem rather neatly:

# docs/command-line.md:239 — tests/bootstrap.sh
ENVIRONMENT="${1:-production}"
VERBOSE="${2:-false}"

We document a bootstrap script that uses VERBOSE as an ordinary local name. It happens to be harmless there (bootstrap is sourced after env resolution, and the assignment isn't exported) — but it shows how naturally these names collide with a user's own variables.

The hazard reproduces trivially. Against an otherwise default run:

$ VERBOSE=true ./bashunit --no-parallel t_test.sh     # verbose mode silently on
$ COVERAGE=true ./bashunit --no-parallel t_test.sh
---------------
Total: 32/3585 (0%)

Coverage report written to: coverage/lcov.info

A CI job that exports COVERAGE=true for an unrelated tool makes bashunit run the whole coverage engine and write files to disk. Nothing in the output attributes that to the bare variable, so there is no way for the user to work out why.

That moves this from "undocumented legacy" to "generic names in the global namespace with side effects", which I'd argue justifies the deprecation cycle.