It does not seems like a symmetrical situation to me: when there is a source->target conversion it makes sense for the source to register interfaces/hook, but here you’re proposing that targets could register themselves. This look like backends that can be swapped when multiple possible target are possible for a given source. However it isn’t such a situation: we can’t “swap targets” and there is a 1:1 mapping from the source (LLVM IR) to the set of targets (Dialects).
Our goal is definitely a 1:1 mapping between LLVM intrinsics and MLIR operations for intrinsics and operations that are implemented in downstream projects. Similarly, we want a 1:1 mapping for LLVM metadata and MLIR dialect attributes that are both defined in downstream project. However, metadata may be nested in other metadata. For example, we may have some custom loop annotation nested in LLVM’s loop metadata node. In this case, the upstream LLVM IR import should import the standard loop metadata, while the downstream project could hook on the loop metadata node and convert the custom annotation to a downstream dialect attribute.
The asymmetry stems from the fact that LLVM IR intrinsics and metadata have do not have a dialect attached. We thus need a way for the dialect interfaces to register which LLVM IR intrinsics and metadata they support. The LLVMImportInterface then makes sure there are only 1:1 mappings between intrinsics and a registered dialect interface.