Less because good code would be written that way, and more to obey the Principle of Least Astonishment. It would be upsetting if raising an exception here caused the reactor thread to die, for example.
succeed_with would fail with 'ArgumentError: 0 for 1' if succeed was called with an empty array . Pretty sure that's not supposed to happen, suspect a bug in Ruby (1.8.7, not 1.9.1): see http://stackoverflow.com/questions/4721708/is-this-a-bug-in-methodto-proc-ruby-1-8-7 for more details on the possible bug.
Abstractly it wouldn't actually have been confusion, because Array#map (the most common case) and Deferrable#map are both functorial map operators, lifting a transformation function into their respective domains. Unfortunately Enumerable#map in general breaks this rule as it always returns an Array, whatever type of thing you called it on. (e.g. Set.new().map(&:upcase) => ). In general, Ruby programmers are trained to expect #map to be something to do with arrays. (Scala programmers have the right idea :)). With that expectation, it's pretty hard to read DG::Deferrable#map. So picking a new, less-encumbered name.
Only thought it did because I was assuming all Deferrables would have a method like #go.
i.e. that Bind behaves as a monadic bind operator as intended. It only works this way when passing a block that returns a Deferrable: misusing #bind! like #map breaks this law and can cause confusion. (Specifically, if a block returns something other than a Deferrable, calling #bind! on that thing breaks us out of the monad - e.g. with a NoMethodError - so the nested syntax doesn't really make sense.)