You can't. Merging of versions has to be complete in order for future merges to work correctly. The proper way to do this is to use the Backport feature to apply the change you want to an ancestor of your working copy.
Monticello dependencies are meant to be used for package development, not package distribution. They're useful when you're developing an "application" that you want to split up into several packages for one reason or another - to have optional components, to factor out a framework that can be used in another application, for licensing reasons, whatever. They're necessary to be able to recreate the extact state of a package version at a later date, since all the dependencies have to be similarly restored.
Tracking dependencies between packages that are developed and distributed separately is a job for SqueakMap. Monticello dependencies won't help here, because they are too precise. For deployment we don't need to recreate an exact package configuration, we just need one that works.
Every time that MC makes a change, it opens a new, sequentially numbered, change set. So each of the MCx changesets represents a separate Monticello operation.
MC largely ignores changesets but tries to be polite about not stomping on them. So it sticks everything it does into numbered MC changesets and then forgets about them.
No. The fileOuts inside .mcz files are not filed in in the usual way. MC parses them into a Snapshot, which can then be loaded. There's no way to emulate preambles, but class-side #initialize methods can be used to do postscript-type stuff.
To support preambles and postscripts, MC would have to be extended to know about them and deal with them properly when it parses/merges/etc the definitions in the fileout.