Hi Michael,
My apologies for not responding sooner - things have been somewhat busy here, and I wanted to give you my full attention. Thank you so much for the detailed answer, and beginning work on support for tenant transforms. I think this will go a long way to achieving what we are looking for. I will try to address each item you mentioned above. Sorry if it’s a big long-winded.
I would personally like to understand what behaviour you’ve seen in Octopus that causes you to interpret that Config Transforms are not first-class citizens, or that we have any plans to deprecate support for them.
To be honest, I guess I am referring to the company support perspective: it seems that transform support is being handled as an afterthought , rather than a v1 release feature. Of course, this is clear from the current discussion, where transform support was not included in the first tenants feature release. I appreciate that it is being pursued now, and that work was done in the background to support it, but I think you can understand what I mean. While variables are fully supported, transforms are not, and this makes it feel like a second-class feature from a strategy perspective. I just wanted to be sure that we can count on the transform support going forward with new features.
If you are comfortable perhaps you could share some specific details about how you use Octopus + Config Transforms etc today?
Sure! Our team (there are others using Octopus internally, but I am speaking just for our team) has 9 projects, 7 of which use transforms (the other two are Linux-based deployments). In those 7 projects together, we deploy about 40 packages, across 6 enviroments (and this is growing). Some of these environments are tenants-as-environments for different data-centers around the world (Production-City1, Production-City2, etc.). We plan on merging these into tenants once the feature set it there, of course. As you can already imagine, each environment requires various differing configurations - connectionStrings, but also internal variables, different logging configurations, email server settings, etc.etc. It can get very unwieldy (imagine nlog configs which differ by tenant), which is why we manage all the configs with transforms.
We leverage SlowCheetah internally so that we can transform config files while developing and building projects. Once we build on the TFS server, we disable the transforms, and let Octopus take care of that, since we don’t want to have to produce tons of different build configurations.
Keeping configs in source control has a huge advantage for us, which is traceability. Octopus simply doesn’t offer such a view for when someone changes a config, and we need to know that the config was changed due to requirement/work item XYZ. This is important for us, and moving the variables out of the software lifecycle process can be an issue.
On a related note, as I mentioned in another thread somewhere, I think that Octopus (as a company) needs to decide where they stand with relation to configuration management specifically. It’s nice to support all the workflows, but at some point, you will be focusing more on one workflow or the other, intentionally or not. I feel it’s also a huge potential for the company if they can offer a robust solution for config management (the other solutions in this space are seriously lacking, IMO, and Octopus is in a unique position to take advantage of that, with its install base). But maybe this is a discussion for another time. 
Would that be something you’re interested in, and help deal with the “first-class citizen” situation you’ve mentioned?
Yes, I think this is the best overall way to do this. Convention-based transforms, plus the ability to specify custom transforms should cover our use-case pretty well. We (or others) will just have to be careful about naming Environments and Tenants with unique names, or there could be some problems (maybe you have a solution for that).
How I like to configure applications
This sounds like a logical way to split up the configs - but again, the disadvantage here is that you have split up the configs. Now, if someone wants to find out why something is configured wrong, they have to check:
The root app.config
The transform(s) for the environment(s)
(Later, the transform(s) for the Tenant(s))
Octopus variables
Octopus Confguration Variables steps
Octopus Custom Transforms steps
And now, even if I found that something is wrong in one of the Octopus items, it is non-trivial to determine who, what, when, and why it was changed. I may now break someone else’s deployment if I put it back (especially with regards to variables and tenants), and they will have the same issue.
I hope this gives an idea of how we work, and where our concerns lie. You and your team do great work, and truly listen to customer feedback, and we really appreciate that. Please keep it up, and keep the channels open!