The webview plugin was (IIRC) the first plugin to use a platform-interface-like concept, and clearly predates most of what is now standard practice. In particular:

1. The platform interface doesn't inherit from PlatformInterface
2. The instance is managed in the app-facing package's class, not the interface package's class, which prevents self-registration
3. The implementations implement rather than extend it (which would have been prevented if 1 weren't true)

Both 2 and 3 are problematic; 2 because it doesn't really allow for unendorsed implementations, and 3 because we are now in a situation where we essentially can't make any change to the platform interface—adding methods is effectively a breaking change. We can't just fix the implementation packages to extend and then change it, because nothing would prevent older versions of the implementation packages from getting a new version of the interface package and failing (unlikely though that would be).

There are two options:

1. Do a breaking change to the interface package, and fix it to look like other packages.
2. Replace the platform interface in a non-breaking way.

It's not clear to me yet whether 2 is possible because the flow is very unusual here, and involves multiple classes, at least on of which is publicly exposed through the app-facing package. (And it's not clear to me yet, not having worked extensively in this plugin, why any of that is true.) My general thought though is that we would define a new, much more standard-looking platform interface within the existing interface package, and then make a default implementation (also in that package) that implements the old interfaces as an adapter. (Because WebviewPlatform is publicly exposed in the app-facing package we'd need a breaking change there to clean that part up, but we're already planning a breaking change at the app-facing level so that's doable.)

/cc @bparrishMines @mvanbeusekom @BeMacized