When two (or more) recipes provide regexps in PACKAGES_DYNAMIC that match a package mentioned in RDEPENDS or PACKAGE_INSTALL, bitbake chooses one of them as the potential RPROVIDER of that package. The selection is based on things like PREFERRED_PROVIDER. This is problematic for external kernel modules. The kernel recipe provides a regex ${KERNEL_PACKAGE_NAME}-module-.* that will match ANY kernel module provided by external module recipes. And since the kernel recipe is likely to be a PREFERRED_PROVIDER, it is likely that the kernel will be chosen as RPROVIDER over the external module even if the external modules dynamic package regex matches more of the package name. It's probably hard to find a method that always picks the correct RPROVIDER, maybe all potential RPROVIDERS should be added to the build graph?
This is a valid problem but it's not clear how to fix it. Adding *all* potential RPROVIDERs would not be the place to start. - Richard Purdie && YP bug review team
PACKAGES_DYNAMIC matching in two recipes is not really supported by bitbake, and it would be really hard to make it figure out how to correctly resolve that without some really hard and expensive logic. The recommended fix is not to use PACKAGES_DYANMIC in your external modules recipe; in most cases this isn't necessary anyway since you should know which modules the recipe is building and can explicitly list them out instead of relying on the regex matching. PACKAGES_DYNAMIC is really only intended for the case where it's impossible to know what packages a recipe will produce beforehand, as is the case with the kernel as the modules will depend on the kernel config. If you can at all possibly know what packages your recipe produces, you should explicitly list them instead of using PACKAGES_DYNAMIC.
You're right, in most cases you probably do know which packages are provided even if dynamic splitting is used. I'm sure it's possible to come up with a scenario where you don't know until the build has been configured which packages will be provided, but at least you will get some kind of indication when the recipe fails to provide a package someone else RDEPENDS on.
For posterity; you should add the (potential) names of any dynamic packages to PACKAGES. Prepend or append according to the do_split_packages' prepend argument used.
Resolving this as we have an agree solution which sounds like the right thing to do to me.