Ey Jason, sorry for the late reply, currently we have a working PoC in a fork of aztec-nr, we’re working on making a PR to aztec-packages to be included on the official release because if you install this aztec-nr then all your dependencies need to use the same aztec-nr, else we face a import issue (“expected AztecAddress found AztecAddress” errors).
About template publishing and consumption, adding the #[contract_template("template_id")] tag at the start of the contract (before #[aztec]) publishes the contract as a template to your compiler, and adding #[aztec(AztecConfig::new().compose("template_id")] consumes it. It’s locally both “publishing” and “consuming” it.
For example, when you create a contract that imports the Token, because the Token has (or will have) the templating tag the compiler should be already aware how to process your contract that templates on top of it.
Template IDs are NOT namespaced, correct, that’s one of the edge cases we’re reviewing on the design. What happens if A templates B and C, and both B and C template some "token", but they use different implementations? Should we then standarize only the external surface of the Token contract (i.e. transfer_private_to_private), or should be standarize also internal methods for maximum compatibility (i.e. internal._increase_private_balance)? Or should we abort compilation if 2 template names overlap.
About “probably follows the standard git-based Noir deps model”, i’m not entirely sure i’m following, it’ll use the same import method as the Nargo files, only that when you import a contract you’re also signaling the compiler that it can be templated.
About Aztec/Noir having plan to extending the language, I really hope for, passing from a PoC to a production ready version requires some consensus on the expected behaviour of every edge case.