I've been thinking about Matt's pushback on webp and SQLite. I think he's right (not that it matters much what I think). Here's an approach that might work.

Problems to solve

1. Matt objects to Performance Lab's approach of bundling various proof-of-concept experiments in a single plugin. He has stated that he prefers "canonical plugins" for such things as webp support and SQLite database support.
2. It's not clear what "canonical plugin" means. The Classic Editor plugin might be an example of that, but it's not called that.
3. Techniques for performance improvement exist that don't apply uniformly to all WordPress installs. Therefore, there may be ways to add value to the overall ecosystem without insisting that all @core-performance work be destined for core inclusion.
4. Hosting providers' site reliability teams likely want features and hooks in performance-oriented code.
5. There's a lot of great work in Performance Lab, which should not be lost.

Observations

Matt seems to favor limited-scope plugins that do one thing well, rather than kitchen-sink plugins that do a lot of things. That is a viable approach. But there's one hazard: each plugin has overhead, so there's a performance cost to having multiple plugins.

The present Performance Lab plugin has a lot of stuff in it. Much of it adds sophisticated Site Health checks, but it also has a variety of operational features.

Suggested course of action

1. Define "canonical performance plugin" and socialize that definition -- get at least some buy-in from the Plugins team, other teams and Matt.
2. Work out, test, and publish guidelines for plugins themselves, to reduce the many-plugins performance penalties.
3. Adapt the Module Proposal process to serve as a Canonical Performance Plugin Proposal process.
4. Create a canonical plugin for webp handling
5. Create a canonical plugin for @aristath's SQLite compatibility work.
6. Refocus Performance Lab on Site Health.

Benefits, issues

• Benefit: These Canonical Performance Plugins can be completed and published, saving regression-test effort.
• Benefit: Hosting providers may see benefits from sponsoring developers to work on these plugins.
• Issue: Is it worthwhile to broaden the scope from "Canonical Performance Plugins" to "Canonical Plugins"?