Yes, this doc section was part of my “literature review” since you had already mentioned it on Stack Overflow or here, so it’s in the “References” section of my notebook.
Most parts (wrapping the model in a function, having subfunctions to create variables or constraints) do apply (and are applied) to my use case. Only I didn’t need dedicated data structures like KnapsackObject.
So the only aspect I didn’t find in that doc (and that was my motivation for making this code design study and posting it here) was the ability to instantiate several replicas of more or less the same inner problem inside one larger problem. Thus my interest in dynamic variable naming. I the end, I decided to use anonynous variables, identified by their String key in a Dict. Having one Dict per inner problem is like having a dedicated namespace for each inner subproblem, so this solves the duplicate name clashes. Still, as a bonus, I append an optional “stage” suffix to the base_name of each variable, so that the String/Latex representation is less ambiguous.