A few thoughts:
The first thing is to understand when Rails will automatically persist records. In a 1:n relationship where a Duck has_many Ducklings and a Duckling belongs_to Duck, the foreign key is stored in the Duckling. If you assign a Duckling to Duck it will persist it right away because it assumes you are working on the Duck and their is just a single change to the Duckling that must be saved right away. If you want to make the association without saving, you assign @duckling.duck_id = @duck.id because that appears you are primarily editing the Duckling and will manage your own saving. The first scenario is really just a convience since you would have to individually save all the ducklings anyway, and if you forget, Rails has no efficient way of remember which to save when you do @duck.save.
Regarding your second scenario, there is no magic I'm afraid. I could definitely see some improvements being made to support this kind of thing, but ultimately I think you can roll something up that's pretty clean.
The first thing is the whole concept of objects[name]&objects[age] is failed even in the absence of a conflicting hash because there's no way to keep the groups coherent. I suppose this could be fixed as long as you can guarantee the presence of every field (been burned by checkboxes in this situation in PHP). But really if you have more than one, you need to index them somehow.
So you can stick your own index in there to make it a hash. But you will also need to distinguish the new from the updates. So it should have a different name such as new_ducklings, new_ducklings. Then you can create a new_ducklings=(hash) method on the Duck model that processes these accordingly.
However, if you are just adding one at a time using RJS, you can just skip the whole index, and have a plain new_duckling hash of fields.
Hopefully that will help a bit. It's definitely not a trivial problem.