Tim Olsen [off-list ref] writes:

At the beginning of merge_recursive(), the local mrtree appears to be
set to some globally defined mrtree which is not null:

No; that "assignment" is just to squelch warning from gcc.  mrtree at that
point is uninitialized.

In merge_trees(), mrtree is the argument **result.  It is at line 1255
that write_tree_from_memory nulls out the pointee of result:
...
Then in write_tree_from_memory() we find the offending return NULL at
line 210:

Breakpoint 8, write_tree_from_memory (o=0x7fffffffd560) at
merge-recursive.c:210
(gdb) list
205				struct cache_entry *ce = active_cache[i];
206				if (ce_stage(ce))
207					output(o, 0, "%d %.*s", ce_stage(ce),
208					       (int)ce_namelen(ce), ce->name);
209			}
210			return NULL;
211		}
212	
213		if (!active_cache_tree)
214			active_cache_tree = cache_tree();
(gdb)

Are you saying write_tree_from_memory() is returning NULL?  That probably
means that in the recursive (i.e. the step that first merges multiple
common ancestors into one) case the merge is getting conflicts.  Do you
see these "There are unmerged index entries" output?

In the recursive case (i.e. o->call_depth is non-zero), process_renames()
and process_entry() are supposed to be forcing the conflicts resolved,
recording the contents with conflict markers if necessary, before the
control gets to that point, so it clearly is a bug very specific to the
recursive merge implementation.