Nothing to do with mixing up units (or even the back end), just plain ol' terrible UX/UI on the website. E.g., ask for "weight of 2 tsp of sugar" and then also click to set the type selector to "sugar, granulated". It'll still show the result as being for a query about 1 tsp of granulated sugar - but why?
This is because clicking the "granulated sugar" selection just appends an override string to the URL, turning the query into a very generic one for "weight of granulated sugar" using API style query semantics. The original input text is still rendered in the box because it was still left at the start of the query string and the override isn't in input text form to replace it. One can see the same result by directly putting "weight of granulated sugar" in the input box, where 1 tsp is just the default quantity used when generating examples with unspecified amounts for most ingredients.
If I were to guess, this was several independently made UX/UI decisions ("leave the originally structured input text in the box as modifiers are clicked", "have default quantities of a material to still generate an example result when a generic query is made", "suggest different types of material to work with", and "a dropdown to select the material should be a modifier") which made sense for isolated components but, later, the components were combined in this flow and nobody tested to see the aggregate behavior no longer makes any sense. Ironically, the issue would likely not exist if modifying the query for the new type was just given to LLM to figure out dynamically in the back end instead of trying to explicitly code the behaviors in the front end.
Wolfram product front ends have historically been broken in little wonky ways like this. Hell, they had a completely half-assed "dark mode" in Mathematica's GUI client until 2025 and just now have added actual visual themes to notebooks in 2026 - the attention tends to be given on the parts beneath the covers.