Ah, you must be further down the journey than I 
Honestly what I suggest violates the isolation/data shouldn’t be mutated ideas (readonly computed might/or might not allow this even if you are doing that yet).
If you truly want the isolation you “could” do a readonly CP in the child/nested template. Then fire an action like so (on the change event) **read more about this pattern from Ben (great blog post btw)
{{my-time-input value=(readonly job.startTime) on-time-change=(action (mut job.startTime))}}
Instead of the mut like you see above you could instead throw the action up to the parent component to “change” that model property. I’m still unsure if this is required/what the ember core team wants everyone doing. I ask because I’m not entirely sold that we should throw out all 2WDB like you see in the post from Ben/hear others talk about.
I’ve only had pain w/ 2WDB when I’m unsure why something changed suddenly. And in my 3+ years writing ember this only happens when I use an observer (heck it just happened to me again 2 weeks ago). I’m trying to balance “don’t reinvent 2WDB with actions/helpers” because in my view it still has a valid place. If you find the data flow is hard to reason about/or you literally can’t find out why something changed it’s time to re-think. I just haven’t had that happen yet with components/ models getting passed around.
All that to say … I’m in the minority these days (not using ember-data for example) but it’s worth asking “what caused us harm” in the 2WDB paradigm and is it worth “re-inventing 2WDB in a more verbose way for every scenario” ?