Yep, I can confirm that also.
I have explored into some of those areas in the past also, and have made discoveries about accessing some of the inner workings of both internal and external iLogic Forms, but it was more difficult than expected, so I would not recommend that others attempt to do so. I had to learn a lot about the XML language, because some of the things involved were written in that XML language, so I had to learn how to navigate that type of data from the perspective of an iLogic rule which is using vb.net Framework language. There are still several things involved that are outside of our control, and that we don't fully understand yet due to the (purposeful) lack of documentation. Doing stuff like that generally requires a relatively high level of curiosity and a determination to dig into unexplored areas, no matter how much time it may take to understand it. Having to learn about another programming language that we may not otherwise have much use for is certainly not ideal. So, attempting to customize the design & contents of iLogic Forms using code in iLogic rules is still not that practical, and relying on that process is likely not something that we should be doing on a regular basis. There is also no guarantees that major changes won't happen within that system at any time. Autodesk actually warns us against using or relying on any code based objects or properties that they have 'hidden' on purpose (or left undocumented), because they could change at any time, and may be unstable.
If we are going to invest that much time, effort, and complexity, we might as well just create a new Windows Form from scratch directly in our iLogic rules instead.
Just my 2 cents worth.
Wesley Crihfield

(Not an Autodesk Employee)