The API for path_provider has a number of significant issues:

• It was design before federation existed, so platform-specific paths (like getExternalCacheDirectories, which is highly Android-specific in practice) are mixed in with abstractions in the app-facing API.
• Some of the APIs were designed for Android APIs that have since been deprecated, and the underlying implementation changed, creating some confusing naming.
• The APIs are almost all pre-desktop, so tend to be mobile-centric.
• The desktop implementation of the documents directory (a widely-used API) is, essentially, wrong, and we can't fix it without a breaking change.
• The iOS/macOS implementation of the temp directory is poorly named, and we don't provide access to the actual temp directory.

The package's API would benefit from being redesigned from scratch. We should:

• Audit all of the existing APIs and open requests for new APIs.
• Make a matrix of all the APIs that it makes sense to support, and what platforms they make sense on.
• Decide what high-level abstractions we want core functionality for (in particular taking a look at the user-created vs. app-created-but-expensive vs app-created-and-easily purgeable, which we have as distinctions right now but in a somewhat platform-fragmented way, and not well named as abstractions).
• Create a two-tiered API system, with common abstractions in path_provider and platform-specific things in path_provider_*, with clear docs in the app-facing package about the existence of the latter, with links to implementation package readmes as examples.

Removing APIs from path_provider would be extremely disruptive as it's such a foundational plugin in the package ecosystem, but we can deprecate the old APIs and create a clean set of new APIs, like we did with url_launcher. That way we don't have to do it as a breaking change, so everyone in the ecosystem can switch to the new APIs gradually, without creating a lot of transitive version conflict problems.