Bazel 8 consumers require legacy compatibility flags and deprecated options

Summary

A Bzlmod consumer using Bazel 8.3.1 currently needs several legacy compatibility overrides and locally patched dependency metadata to build Valdi across web/test/Android configurations. Some flags suppress hard Bazel 8 incompatibilities; others produce deprecation warnings and are likely to become hard failures in a future Bazel release.

This is an anonymized consumer report intended as an umbrella/checklist for declaring and testing a supported Bazel 8 configuration.

Environment

• Bazel 8.3.1
• macOS arm64 consumer; Android and web/test targets exercised
• Valdi through Bzlmod
• Hermetic Android SDK and NDK
• Patched rules_kotlin 1.9.0 dependency stack

Compatibility overrides currently required

# Host-specific hermetic NDK globs can be empty on macOS.
common --noincompatible_disallow_empty_glob

# The patched rules_kotlin 1.9.0 graph still uses legacy APIs/providers.
common --incompatible_disallow_struct_provider_syntax=false
common --noincompatible_disallow_ctx_resolve_tools

# Android/rules_kotlin migration compatibility.
common --experimental_google_legacy_api=true
common --experimental_enable_android_migration_apis=true
common --incompatible_java_common_parameters=false

The consumer also still receives/uses deprecated configuration such as:

build --android_crosstool_top=@androidndk//:toolchain
build --experimental_generate_json_trace_profile

Bazel reports that android_crosstool_top is deprecated in favor of Android platforms and that experimental_generate_json_trace_profile has been replaced by generate_json_trace_profile.

The consumer's local registry additionally carries compatibility patches around the rules_kotlin module extension and hermetic Android SDK integration. Without the corresponding switches/patches, analysis fails before application code is reached.

Expected result

Valdi should either:

• build from a documented Bzlmod consumer template on a named Bazel 8 release without legacy incompatible switches, or
• explicitly publish the supported Bazel range and a maintained compatibility configuration while migration is in progress.

Proposed cleanup checklist

• Add a minimal external-consumer CI fixture, not only in-repository targets.
• Exercise Bazel 8 on macOS and Linux for a Valdi test, exported web package, and Android application analysis/build.
• Replace or update patched rules_kotlin APIs so struct-provider and ctx.resolve_tools compatibility switches can be removed.
• Make host-dependent NDK file selection explicit (select, repository generation, or intentional allow_empty) instead of globally permitting empty globs.
• Complete the Android-platform/toolchain migration and remove android_crosstool_top.
• Rename the trace-profile option to its supported non-experimental spelling.
• Remove each compatibility flag individually in CI so regressions cannot silently add it back.
• Document the supported Bazel/JDK/Android toolchain matrix for external Bzlmod consumers.

An umbrella issue seems useful because the switches interact in the same consumer bootstrap path, but individual checklist items can be split if that is easier to land.

Start with the Bazelrc compatibility overrides, the Bzlmod consumer bootstrap path, and the proposed external-consumer CI fixture. Run Bazel 8.3.1 against the listed macOS and Linux web, test, and Android configurations. Done means a documented supported Bazel/JDK/Android matrix with compatibility flags and patched dependency work removed or explicitly maintained.