The Dart registration that was added for dartPluginClass-based plugins on desktop is based on the resolver logic (for handling alternate, unendorsed implementations) that was added at the same time. The resolver incorrectly assumes that a plugin implementation must be separate from the app-facing package, and thus ignores any Dart plugin class that doesn't have an implements keyword. Since the resolver ignores it, no registration call is generated when that keyword isn't there.

From a code standpoint this is easy to fix, but there is an ecosystem problem: dartPluginClass existed for about a year before registration support was added. In practice there are plugins in the wild--probably almost all of them since we haven't documented registration yet, and including some published versions of path_provider and shared_preferences--that use dartPluginClass but have no registerWith() method defined. Generating a registration call for those plugins is build-breaking.

This would have been a problem when the support originally landed except that we were saved by the bug described here; none of those existing plugins have implements either, so no call is generated. Fixing this bug will create that breakage event.

So far I've come up with three options:

1. Just break things. It's a trivial fix for plugin authors, and there are likely only a handful of such plugins in existence (and we could pre-fix any public ones by sending PRs and waiting for them to land and publish). The problem is clients: anyone depending on these plugins--most concerningly anyone with an old version of path_provider or shared_preferencesin their lock file, which could be a lot of people--will get broken builds, and the fix (updating plugins) will probably not be obvious to most people (although the plugin class will at least be in the error message).
2. Make a new property (e.g., hasRegistration: true) that people have to put in for inline implementations. We could warn if it's not there, and say that at some point that will become the default as a breaking change, at which point we remove it. This will avoid breaking most people, but it'll mean we'll be stuck with this temporary property--and the inconsistent behavior of when registration works--for a while (six months? a year?)
3. Grep the plugin source at build time for a registerWith()and use that to decide (warning if missing). It's kind of gross, and could potentially be wrong (although I doubt it in practice), but doesn't add a property that we plan to remove again.

/cc @cbracken FYI