//third_party/WebKit/public:mojo_bindings has definitions like:

  export_class_attribute = "CONTENT_EXPORT"
  export_define = "CONTENT_IMPLEMENTATION=1"
  export_header = "content/common/content_export.h"

That will insert CONTENT_EXPORT into the generated bindings code. It also has CONTENT_IMPLEMENTATION=1 so the result only makes sense to be used inside content.

I also saw this comment:
"""  # The chromium variant must be linked with content and use the same export
  # settings in component build because of the WebBluetoothDeviceId typemap
  # inside content.
"""

It makes sense to me to move those mojoms doesn't require content-only typemaps into a new target. What could we do otherwise? :) Interfaces using content-only types are supposed to be consumed by content only.

Triage. Updating this to clarify what the bug actually is.

AFAICT this is only a problem because for a Blink-defined mojom, we often link the non-Blink variant into the content/common component (as described in comment #1) and export its symbols from there. And AFAICT there are only two reasons we do that:

1. A typemap has a dependency which belongs to content/common, and it's hard to factor out; or
2. A developer unnecessarily followed this pattern because other mojoms were doing it

It seems to me that the solution is to have more granular bindings targets, and to migrate their typemap dependencies into isolated components, so this is a problem not with mojo bindings in general but with having massive component targets. It also seems like something that needs to be addressed on a per-mojom basis, rather than something to be solved by/within Mojo per se.