Hi Jia Wei,
I understand this can be confusing. Let me explain some fundamental ideas in SUAVE so it makes sense how to do what you want.
SUAVE was intended for optimization since day one. The analyses try to give an answer whether realistic or not (for example you can burn more fuel than the airplane has mass). This was intended so that an optimizer could try something crazy and through enforcing constraints eventually converge to the correct solution. Many codes break when you connect to an optimizer for this very reason. It becomes the users responsibility to properly constrain the problem and consequently leads to a learning curve for SUAVE.
Similarly, for weight estimation you've noticed that the component level, and OEW, changes when you change the geometry dimensions. However, the MTOW will stay fixed because that is an input to the weight estimation (it sizes spars etc..). The takeoff weight is also an input, an aircraft operator can choose how much stuff to takeoff with, it's not always going to be MTOW. Thus, MTOW and takeoff weight are functionally independent of dimensions. You'll need to add constraints.
At one point we tried to put together a one size fits all solution for sizing, but we found that every problem had totally different needs. There are some sizing scripts, but they're not all encompassing, here's a folder of useful scripts
To answer your final questions. No, the wing, tails, and energy network move independently of the fuselage (I suggest putting together a simple sizing rule for this if you want them to move). CG and stability will change (if you call those functions) when you change the geometry. Yes, they will change the performance. However, trim drag is not well accounted for in SUAVE right now. There is a mark up for it, but the assumption is that the static margin is in a reasonable range.
None of what I mentioned requires changing SUAVE, it's just problem formulation.
Please keep asking questions, there are a lot nuances here. This probably makes no sense to why we do things this way, but from another users perspective your design flow makes no sense for their problem either.