Coexisting tf.keras and standalone Keras 3 in one project: dependency and import strategy

Goal

Migrate a TensorFlow-based training project to standalone Keras 3 for future backend portability, while some third-party dependencies still import from tensorflow import keras internally. The project currently runs on TensorFlow 2.16, where tf.keras aliases Keras 3, but the team wants a deliberate policy rather than an accidental mix.

Constraints and uncertainty

Mixing import keras and from tensorflow import keras in one process can, depending on installed versions, produce two distinct package instances whose model and layer objects are not interchangeable. Existing artifacts include legacy .h5 checkpoints saved under Keras 2, and the native format going forward would be .keras. Custom layers were written against TF-only symbols, so non-TF backends are aspirational rather than guaranteed. Exact alias and removal behavior is version-sensitive and must be confirmed against the installed keras and tensorflow packages.

Questions

• Should the project pin standalone keras and ban tf.keras imports entirely, or is a controlled coexistence safe under TF 2.16+ where the alias exists?
• What is the right dependency-pinning strategy so a transitive dependency cannot silently pull a conflicting Keras major version?
• Is converting legacy .h5 artifacts to .keras a prerequisite for the migration, or can both formats be supported during a transition window?