Lucee 5 beta: a direct question about createObject()

G'day:
In an attempt to get a direct straight answer out of Micha regarding createObject() and loadComponent(), I have posed a very direct question about it on the Lucee Google Group:

createObject(). Focused question...

I've had several (well: a few) discussions with Micha regarding createObject(), and its future, vis-a-vis createComponent() (now loadComponent()). However I cannot see anywhere that Micha has answered one of my questions without getting distracted by other considerations. So I'll ask again.

This is the question, and the only thing I would like ppl to focus on or comment on in this thread (if that's poss):

How is it we need a new function to do CFML object instantiation (with init()), when we could just do this (orange already exists; green is the solution):

• createObject("component", "path.to.component")
  Continues to do the same as now: creates object does NOT run init(), returns it (needed for backwards compat, but can be deprecated in favour of the third option)
• createObject("java", "path.to.class")
  continues to do the same as now for backwards compat reasons (this is not being contested, it needs to be the case. Can be deprecated)
• createObject("path.to.component")
  continues to do the same as now: creates object does NOT run init(), returns it (this is a requirement for framework developers)
• createObject("path.to.component", initArgs)
  creates object, does init() it, returns it. Solves perceived problem loadInstance() fulfils

This does not conflict with any of the syntax needed for backwards compat, continues to fulfil the requirement for delivering un-init-ed objects, and solves his particular requirement all without a new function, and stays in-keeping with current CFML usage.

Why can this not be done?

Answers will be disqualified if:

• they do not answer that one question directly
• they refer to previous discussions without just answering the question directly
• they focus on the untidiness of the inner workings of createObject() implementation which should not impact how the outward implementation of CFML effected.
• they use specious excuses like "you can't have a function that sometimes does, sometimes doesn't call init()". That is not valid: yes you can.
• they leverage a desire to deprecate createObject() entirely, because that position only comes after it's justified that it even ought to be deprecated.
• it dwells on the invalidity of returning un-init-ed objects, or how bad that is in theory without actually answering this question. Anyway: a need has been identified for this, so it's not on the table in the context of this question anyhow.

Answers will be accepted but marked down if they deal in metaphor and anecdote rather than just getting on with it and directly answering the actual question.

Hopefully I can elicit a straight answer from him for once. Micha: answer on the mailing list, not here pls. Any answer here I will copy to the mailing list.

Cheers.

--
Adam