> You don’t need a shopping cart either. Just make the user write down the skus from your online catalog and send you a purchase order.

I think this is a way to do it, I had thought also of such a thing before. You can send a "computer payment file" which includes the product ID numbers (and parameters if applicable), the total price that the customer expects to pay, a signature, and encrypted data for use with the bank or credit card company (or some specification of store credit, if you are using that instead).

The existing use of "shopping cart" cookie can still be available as an alternative as well though, in case you do not want to use (or cannot use) the "computer payment file"; then it can provide its UI but you can also use your own if you have your own implementation.

> Adding a language select option on a multinational site seems pretty table stakes in my experience. Plenty often the user does not wish to use the same language as their system/browser. Switching your system’s default language just for one site is a huge hassle.

This is true. However, it would also be helpful to be able to change the settings (including languages, and HTTP request headers) per URL prefix, which would also be another way. This does not mean that the setting cannot also be available as a cookie, which will override the Accept-Language header if both are present in the request.

There is also user authentication; cookies are not really the best way to do that either. I think X.509 client certificates are a better way. However, other methods can still be provided for compatibility for users who do want to use it.

And then, there is more other stuff too, they can also be done in other ways.

Note that all of the above stuff means that many things can work with JavaScripts and cookies disabled (or unavailable), but enabling them will provide a way of working that does not require these other things too.