mod_dav_svn returns generic 401 for expired LDAP passwords with no way to distinguish them from bad credentials

Short answer

No. With mod_dav_svn plus mod_authnz_ldap there is no supported configuration that turns an expired LDAP password into a distinguishable HTTP response. Both a wrong password and an expired password surface as an LDAP bind failure (LDAP error 49, invalidCredentials), and Apache maps any bind failure to a plain 401 with no differentiating body. This is partly deliberate: distinguishing "expired" from "wrong" leaks account state and aids enumeration, so the generic 401 is a security posture, not just a missing feature.

What is confirmed vs. likely

Confirmed behavior: HTTP Basic/Digest auth is stateless. The Subversion client resends credentials on every request, and mod_authnz_ldap re-binds to LDAP per request (modulo a short internal bind cache). So once a password expires in the directory, the next request fails server-side immediately. There is no server-side session keeping the user alive.

Likely explanation for your stale-access window: the directory itself can carry more detail — Active Directory returns subcodes in the bind error string (e.g., data 773, "user must reset password"), and OpenLDAP with ppolicy can return policy controls — but mod_authnz_ldap does not propagate these into the HTTP response. Depending on httpd version and LogLevel, some of this detail may appear in the Apache error log; treat that as version-sensitive and verify on your build rather than assuming the subcode will show up.

The stale-identity risk you describe is real but narrower than it first appears: because credentials are re-validated every request, an expired cached password is rejected on the next request. The genuine gap is when the user changed the password elsewhere and the client keeps silently sending the old one from ~/.subversion/auth/ — that fails too, but the user experience is a confusing 401 loop, not continued access. Continued access after expiration should not happen; if you observe it, suspect the mod_ldap bind cache or a second authentication path.

Answering your three questions directly

1. Distinguishable response: Not via configuration. Your options are operational: mine the directory-side logs (AD security events, slapd logs) where the real failure reason is recorded, raise Apache LogLevel to debug and check whether your httpd build logs the LDAP diagnostic message, and provide a self-service password reset portal since the 401 can never carry the hint.
2. Forcing re-evaluation: Unnecessary for expiration — the server already re-binds per request, so authz is always evaluated against the currently-validated identity. What the server cannot do is purge the client-side auth cache; it is keyed by realm string and lives entirely on the client. You can reduce server-side caching with mod_ldap cache directives (e.g., a short LDAPCacheTTL) if your build caches successful binds.
3. Verification: See below.

Verification procedure

1. Expire a test account's password in the directory.
2. Run svn info https://host/svn/repo --no-auth-cache --non-interactive and confirm a 401 in the Apache access log.
3. Repeat with the normal client cache populated from a previous successful login. The expired cached password should still be rejected on the next request — this proves per-request re-validation.
4. Check the directory side (AD event viewer or slapd logs) to confirm the expiration reason is recorded there, since HTTP will never show it.
5. Clear ~/.subversion/auth/ and confirm the client prompts again rather than reusing stale credentials.

If step 3 unexpectedly succeeds, that is the one diagnostic detail that changes the recommendation: report which access method succeeded and whether mod_ldap caching is enabled, because that would indicate a caching or alternate-auth-path problem rather than expected behavior.