bicep-registry-modules VS PSBicep

We have a separate parameter file for every landing zone instance (our implementation is a bare-bones CAF landing zone, kinda like https://github.com/Azure/bicep-registry-modules/tree/main/modules/lz/sub-vending, which is avaible from bicep public registry), where instance is for example a separate environment (dev/test/prod). This parameter file only represents the configuration, so things like subnets, nsgs and so on, and it has nothing to do with the landing zone implementation as such.

As you point out, it is another layer of abstraction that can make it more complex. Specifically it will add a pain point with the replication of the modules from /ResourceModules to the private repo. (I dont have a good solution for that at the moment) Microsoft has a public container registry (https://github.com/Azure/bicep-registry-modules) that someday may be updated to contain everything in /ResourceModules

Still a work in progress, but the official bicep registry - https://github.com/Azure/bicep-registry-modules

Currently the automated testing we have in the pipeline is only building the bicep into ARM, and running psrule against the biceps (which, I think, is essentially the same thing). We used to run the Test-command of PSBicep-module (https://github.com/PSBicep/PSBicep/blob/main/Docs/Help/Test-BicepFile.md), but ran into problems with that one, as the module tends to lack behind latest bicep features a bit - same thing with a lot of tooling like psrule.