Third-party provider funcs in our API: did we expose too much?

Can anyone explain to me why the following symbols are exposed in the public
Subversion API?

   svn_auth_get_platform_specific_provider
   svn_auth_get_windows_simple_provider
   svn_auth_get_windows_ssl_client_cert_pw_provider
   svn_auth_get_windows_ssl_server_trust_provider
   svn_auth_get_keychain_simple_provider
   svn_auth_get_keychain_ssl_client_cert_pw_provider
   svn_auth_get_gnome_keyring_simple_provider
   svn_auth_get_gnome_keyring_ssl_client_cert_pw_provider
   svn_auth_get_kwallet_simple_provider
   svn_auth_get_kwallet_ssl_client_cert_pw_provider
   svn_auth_get_gpg_agent_simple_provider
   svn_auth_gnome_keyring_version
   svn_auth_kwallet_version

I mean, I recognize the value of what each of these functions provides, but
it seems to me that svn_auth_get_platform_specific_client_providers() pretty
much obsoletes all them.

What's more, this latter single function actually honors the runtime
configuration's "password-stores" option value (which dictates the
availability and preferred specific ordering of third-party providers),
while the aforementioned list of interfaces almost begs API consumers to
fetch providers individually and plop them into the auth subsystem's
providers list without regard to the user-configured availability and order.

Am I missing something? Is this just a holdover from the days when we
discouraged the use of private-but-non-static functions?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development