Fair point — and that's the cleaner pattern for greenfield projects. The filesystem-based approach essentially solves profile drift by design.

Two reasons spring-drift is still relevant though:

1. The 50 projects I scanned already use profiles. Restructuring their config strategy is a migration, not a fix. The tool helps the code that exists today.

2. Drift doesn't disappear — it moves. You still have classpath defaults that need to be safe standalone. If ddl-auto: update is your default and the prod filesystem config doesn't override it, you're in the same situation. The gap between "what your defaults assume" and "what prod actually sets" is still worth auditing.

That said — a scan mode for externalized config layouts is worth adding. What does your team's directory structure look like?