Can plugins override built-in operators with the same name?

Description

I would like to confirm whether TensorRT intentionally does not support overriding built-in operators with plugins that share the same operator name. In current usage, when a built-in operator exists, registering a plugin with the same name appears to have no effect.

If this is the expected behavior, it can be limiting in practice. Users register a same-named plugin obviously indicates that the built-in implementation is insufficient—for example, due to performance issues or incomplete shape or dimension support. Blocking override removes a reasonable optimization path.

ONNX is an intermediate representation and should remain generic and extensible. Forcing users to invent non-standard operator names solely to bypass TensorRT’s built-in behavior breaks semantic clarity, reduces portability, and is conceptually awkward, since the plugin still implements the same logical operator.

Request

Please consider supporting a conflict-resolution mechanism between built-in operators and plugins, such as explicit priority, precedence rules, or versioning, so users can intentionally choose a custom plugin over the default implementation.

This would improve extensibility while preserving parser clean and ONNX graph standard.

No file, test, or entry point is named. Start by locating TensorRT’s built-in operator resolution and plugin registration behavior, then document the current precedence rules and the requested conflict-resolution options. Done would require a maintainer-approved design or implementation scope for intentionally selecting a same-named plugin.