Both sentences require browsers to support 100 characters.

Both sentences permit browsers to support 101 characters.

Exactly, they're functionally the same.

On second pass, you're right. They're the same.

Yes but "you must support up to 100 characters" also has no upper bound - supporting 200 characters also fits that requirement.

So if you were a programmer on a project and you were given a spec that says "up to 100", you would just make it unbounded, and for all intents and purposes completely ignore the spec?

"Must" and "Must Not" are keywords in formal spec. If it says "Must support up to 100" and doesn't say "Must Not support over 100" then I would consider the upper limit to be whatever limit is sane for the data type.

So you would pick an arbitrary upper limit based on your own notion of what is sane. Picking such a limit, you would still need to write the same error handling code for limits, but it would happen at maybe 200. And the next programmer who inherits your code looks at the spec and your code and has to guess "why 200"? And it becomes lore. Which is specifically worse than writing to the spec.

The spec doesn't exist. It's undefined. "Must support up to 100" is not a limit, it's a lower bound.

I can see where you're coming from, it does read like "MUST support up to 100 characters (and MAY support more of you choose).

But honestly I think it's a bad practice to build the "may" part, because it's not explicit. The person who wrote the spec just as easily could have intended it to be "MUST support up to 100 (and may not go over 100)". So by not setting a bound you're gambling with your implementation being rejected, but setting a bound at 100 satisfies both possible "implied clauses" of the requirement and should not be rejected.

The supported URL length is at least 100 characters, not the URL length.