The changeset API is a very functional one. Given a base and an input of how things are meant to look like at the end ecto figures out all the necessary changes to get to that endresult. One can then validate all the changes to prevent disallowed invariant and eventually can check if the changes are good to go or not.
The API however is not stateful in the sense that after such a round of validation one could go back and add more changes and have the changeset know which errors won’t apply anymore. A changeset doesn’t keep track of which validations were applied end how, it only keeps their results – errors and metadata – around.
So whenever there is new input with changes to be validated the expectation is that a new changeset is created, which again is run through the same validation paths as the previous.
The problem with changeset.params is that it stores the parameters as given on changeset creation, thus not reflecting the changes we made with put_embed.
If the goal is to handle errors you could split creation of the changeset from validation, so you can do the edits on the changeset in between those two calls.