On the Rails merger with Merb

I think overall it will be a good thing.

There obviously are a lot of common goals between the two frameworks but I'm more interested in how they merge some of the more controversial differences. Both teams have already mentioned modularity and internal APIs as something that Rails is going to adopt, but what about some of the smaller differences?
Some of the more difficult issues to be resolved might be:

• Merb's requirement for an explicit call to render or display - will that be optional?
• Merb's mailer and exception handling - Merb way is probably superior
• Rails' extensive use of monkey patching and magic versus Merb's preference for code simplicity
• Rails' use of test/unit versus Merb's RSpec preference - will all of rails internal tests be rewritten in RSpec?
• slices versus engines - support both??
  

None of these issues are huge and insurmountable but there are a lot of differences that will have to be debated. Will it be a full or partial buy-in to the Merb philosophy by the Rails team? If it is a full buy-in, Rails backward compatibility will probably suffer. If Rails 3.0 is only a partial merge of the Merb way, merbists may look at Rails 3.0 as a watered-down bastardization of Merb and just continue using Merb 1.x.

I'm certainly looking forward to seeing what they come up with!