The issue I found is that if the stack size (or likely any variable) in a formula points to a parameter, say [P1] that is also marked as an ingredient of another parameter, say [P0], then when re-selecting contents it will run the formula as if the stack size is 1, setting the placed object to the formula result instead of maintaining the static value. Thus, the reconfigured blueprint loses the entire entry for said parameters because the numerical value changed. This can be avoided by setting the static value to the predicted result of the formula, but likely this seems to be a bug as placing the unconfigured blueprint should maintain the static values (as it does when not pointed to an ingredient).
As per my example, the final three parameters filled in with 777, 666, 555 will paste the formula instead of said static value. Each formula references the stack size of P1, which is marked as an ingredient of P0. Thus, the formula runs as if stack size is 1, outputting as such:
((p1_s)*cr*12)-((p1_s)*80) = 496
((p1_s)*cr*12)-((p1_s)*(80*2)) = 416
(p1_s)*80 = 80
Simply removing P1's "ingredient of:" field will run the expected result, the pasted blueprint will maintain the 777/666/555 values and can be reconfigured with select new contents properly.
If a player wants to paste such a blueprint without setting the parameters to modify it and then reselect new contents, the expected result would be to paste only the static value in parameter field and not run any formulas referencing undefined parameters so that players can easily modify blueprints as such without having to fill the static value as the formula result.