I’m not sure I understand the question. When I moved to modules I had previously been using Amalgamated. I like having the used source in my project because I can then tag it in Git and have a reproducable version. If I use a static lib, I can check in the lib, but it is awfully nice to have all the source exactly as you released (yes, you can do sub projects, etc., I just find this clean and clear).
It wasn’t immediately clear to me how Jule’s intended the files to be organized, so using the Introjucer gave me a good look. It also helped me setup all the configuration options. I then moved the generated folders as is into my existing project. Another thing I found helpful was Introjucer knowing the dependancies. On the mobile platforms, the total JUCE library is getting pretty big. Especially since you can end up with multiple copies in your executable (ex. to support older iOS deployment targets you need to build using two different archs, similiarly, you can end up with two or three different builds in an Android package). The ability to go lighter weight with modules did end up cutting compiled code size (which has me wondering about the compilers, but that is another subject).
You can definitely setup modules without Introjucer. When I first looked at Android, 4.0x was not working correctly. It turned out to be OS changes, but it initiallly had me looking at building. I ended up setting up that building from scratch. It was a pain, but doable.
Vinn has some strong opinions about modules organization, the Introjucer, etc. but I haven’t followed those discussions closely enough to have an opinion either way on his specific points. For me, modules is a lot easier than amalgamation. And now that the Introjucer automates all the crud I was doing by hand for Android (where you have to change even your folder heirarchy to reflect your app name), I’m pretty much in the ‘All Hail the Introjucer!’ crowd too.
But, again, it isn’t absolutely necessary and I can’t really comment on Vinn’s specific issues.