+1 for alternative 1, “before_save on: :create and before_save on: :update could be supported (and the same for after_save and after_commit)”.
What is the difference between before_create :foo and before_save :foo, on: :create?
I think this is more a documentation issue and maybe (2.) can help to avoid confusion.
I don’t like (1.) and (3.).
I think this is more a documentation issue and maybe (2.) can help to avoid confusion.
The downside of (2.) is committing to keep an inconsistent API. Rails is a large framework to learn already. It’s great to have documentation, but it’s even better when things are so consistent and obvious that you don’t need the docs. That’s optimizing for programmer happiness. 
A possible advantage of (1.) is that is that it could be extended to hook into user-defined events, like before_save on: :archive, or before_validation on: :publish. But that’s a separate discussion.
A possible advantage of (3.) is that it’s more discoverable: before_save_validation and before_create_validation would be listed in @model.methods and in Rdoc.
The problem with (1.) is that before_save :foo, on: :create and before_create :foo do the same thing. For me this cause more confusion.
About (3.) being listed in RDoc we can do the same right now and explicitly say that before_save doesn’t accept :on option. Like a said this is more a documentation issue.
validate :foo, presence: true
and
validate_presence_of :foo
Also do the same thing. This is a slightly different use case but I’m +1 for making before_save consistent with before_validation as far as an :on option goes. This has tripped me up before as well.
Thanks,
Adam Hunter
Rafael - Now I see what you mean; you don’t want two names for the same thing. I agree.
What I was trying to say is let’s pick a consistent callback syntax, support that, and deprecate the others. This doesn’t have to be done quickly; I just think it’s a good direction to head.