If an end user follows the documentation for the examples/cloud-router-routing-protocols example they'll end up using a version of the module that doesn't have as many options as the submodule it's trying to explain how to use (ie. modules/cloud-router-routing-protocols). This can lead the end user to conclude things like "oh their module doesn't support a bgp authentication key", when really it's just the example of that module that doesn't have the bgp_auth_key shown.
I would propose either removing "examples/cloud-router-routing-protocols" (which I realize could make it harder to find if end users don't think to check the submodule drop down on the terraform registry) or taking care to make sure it's fully in sync with the "modules/cloud-router-routing-protocols" such that all possible inputs and outputs are exposed.
If an end user follows the documentation for the examples/cloud-router-routing-protocols example they'll end up using a version of the module that doesn't have as many options as the submodule it's trying to explain how to use (ie. modules/cloud-router-routing-protocols). This can lead the end user to conclude things like "oh their module doesn't support a bgp authentication key", when really it's just the example of that module that doesn't have the bgp_auth_key shown.
I would propose either removing "examples/cloud-router-routing-protocols" (which I realize could make it harder to find if end users don't think to check the submodule drop down on the terraform registry) or taking care to make sure it's fully in sync with the "modules/cloud-router-routing-protocols" such that all possible inputs and outputs are exposed.