I think vfork(2) can be evaluated quite favorably in cost-benefit terms:

	cost	: to application, zero (compatible interface)
		: to kernel, low
	
	benefit : substantially more efficient. Although cpu's are getting
		  faster, the absolute cost of coherency ops and cache
		  misses is largely static, so the relative cost is
		  climbing at the same rate as CPU speeds are
		  increasing. I predict that the relative benefit of
		  vfork() will increase in the future. There is a great
		  deal of evidence that shows that operating system
		  services do not increase in speed at the same slope
		  as user-mode benchmark performance. I have given
		  two reasons above for this observed effect.

Also, IMHO, I don't think Jason needs to justify reimplementing the internals
of a historical interface. For better or for worse, that interface was
created long ago, and I recommend it be accepted as a fact of life. (Reminder,
this paragraph was labelled MHO.)