To be clear, the most valuable thing about the old GUI, to us, was not the canvas style, though that view was cool for presentation, but the ability to graphically control the GUI.
That sounds, good. We did recognize that the density of the old GUI was not very optimal for large deployments. My colleague ended up zooming way out in the web-browser tab so he could see the whole thing.
That would be great! My team would love to have a meeting. We use Jitsi Meet for our meetings and we could work out a time to have a web conference.
That sounds good. Me and my team have experience with both full-stack applications and web application/website frontends and we have entertained the idea of writing our own GUI prototype as well. As long as the API is there we will be free to experiment with the UX, and we can collaborate on any API changes that may be necessary.
Yes! I’m so glad that Juju was flexible enough that we could push it so far in the direction of our goals with the Lucky framework. And it is refreshing that Canonical and the community is welcoming to different approaches and ideas. 
I actually totally agree with that, and I was very pleased to see the new relation “mocking” setup that the Operator framework had for testing, something I definitely want to work into any frameworks that we make. We think, though, that writing charms demands it own application development tools, similarly to how you have tools such as Cargo and NPM for Rust and NodeJS.
With the actor-based messaging strategy we think that this development workflow can be modularized in a way that is also language agnostic.
I agree. It is something that is very difficult to tell how it will play out practically before actually using, and it is also rather based on developer preference. I don’t think there is any value in trying to unify the approaches, but for now give some time for both approaches to prove themselves out.
It does produce a little bit of a community split, maybe, with two different charming methodologies, but at the same time it allows different developers to take the path that is most close to the way that they think and work. Eventually it may be that the lessons learned from these frameworks will manifest in one framework that solves all of our problems.
Absolutely. Thank you for your responses as well. Your points have helped me understand better the motivation behind the designs you are currently pursuing.
We do have different perspectives which is actually good, because hopefully we collectively can represent a larger spectrum of potential charm developers and users of Juju.
It may seem ironic how we are already considering developing yet another charming framework ( the design of which was outined in [Idea] Actor Charming Framework For Juju ) after producing Lucky, but Lucky was essential to helping us understand what we felt like Juju still needed help with, even after solving a lot of our pain points.
We are wanting to establish an easy-to-understand way to develop charms that is maximally cross-platform and language agnostic. We think the actor framework is a way to do that, but it needs proving out.
So while we use Juju and Lucky to make charms for now, we will experiment to see if we can bring Juju even further into our vision of simple and powerful automation design framework.