Here's a strange little bug that tells you more about how modern spreadsheets think than most documentation ever will. A user on Reddit recently discovered that naming a LAMBDA parameter `par1` breaks the function entirely, while `par` works fine. The error message is generic, "you've entered too few arguments", and there's no help article, no autofill hint, not even a stray forum post explaining why. That silence is the real problem.
What happened here is that `par1` collides with something internal to the spreadsheet engine. The name turned blue in the editor, which is the same color the software uses for reserved keywords and built-in functions. So the parser treated `par1` as a predefined term, not a user-defined variable. It essentially erased the parameter from the function signature, leaving the LAMBDA expecting fewer arguments than you supplied. The result is a cryptic failure that looks like user error but is actually a design blind spot. This isn't a fringe case, either. Naming conventions like `val1`, `arg2`, or `tmp3` are exactly the kind of shorthand a power user reaches for when building complex formulas under time pressure.
For anyone working with LAMBDA and LET, two of the most powerful additions to modern spreadsheets, this is a practical warning. You cannot trust that a variable name is safe just because it looks reasonable. The engine has a hidden namespace of reserved identifiers, and it does not surface them in the interface. There is no autocomplete list of forbidden names, no warning when you type one, and no explanation in the error. The only defense is trial and error, which is not a viable workflow for production models or shared workbooks.
Our take is straightforward: this is a transparency failure in a tool that asks users to think like programmers. When you introduce programming concepts like named parameters and scoped variables, you inherit the responsibility of making the rules discoverable. A spreadsheet is not a compiler; its users expect the UI to protect them from invisible landmines. Microsoft and Google both need to publish a complete list of reserved parameter names and, better yet, block them at the point of entry with a clear message. Until then, if your LAMBDA suddenly stops working and the error makes no sense, check your variable names. `par1` is not a parameter. It's a trap.