First, the link in my previous post is a red herring: even though Next.js is involved it really is something handled by the website, not the framework.
Still, Next.js does use BigInt internally and that is what breaks everything, including old versions of Safari which prompted the fix that also benefited Pale Moon.
From what I could gather, BigInt is used (or "was used", as the code has been refactored to not use BigInt anymore, apparently) to create a Bloom filter.
In short, a Bloom filter is an algorithm to know if the requested element is present inside a set within a certain margin of error. For a more detailed explanation go to Wikipedia or something, all we need to know here is that Bloom filters are used to recognize whether a certain element has a certain property.
Naturally, one has to wonder why a web framework even need a bloom filter. Intuitively a framework just needs to provide some ready-made blocks (functions, classes, etc.) to quickstart the actual application. It is then up to the application developers to define all the paths, the objects to handle requests, etc.
Here is the catch: Next.js also intercepts "routing" and guides the browser to send requests differently than what is displayed in the user interface (e.g. the address bar). "Routing" in this case, is the process of assigning a certain content with an arbitrary string, which is then displayed as the "resource path" in the browser's address bar.
In the old days, requesting the resource
http://domain.tld/path/to/resource/file.html would make the server literally access the file system to access the folders
path/to/resource and then grab the actual file "file.html" from there, which would then be served to the client in the HTTP response body.
For many reasons this behaviour was considered undesirable, thus server-side framework (e.g. Ruby on Rails) started blocking this file system scan, instead directing every resource request to their internal code --- what has been called routing. Through this routing, requesting the
path/to/resource/file.html resource does not mean actually accessing the
path/to/resource/file.html file; instead, it means the framework will check an internal data structure for an object associated with the requested resource, will then execute some action on this object (e.g. the object is an instance of a class in the OOP paradigm and the framework executes one or more of its methods) and the result of this action is then given to the client.
This behaviour allowed for URLs that would've otherwise be impossible or very hard to manage. For example, it allows URLs like
https://domain.tld/accounts/1 to uniquely identify the account page of the registered user whose identifier is 1 (e.g. inside a database) with extreme ease.
During the time web developers started pushing for single-page applications, that is, sites whose content was served all in one request and "navigation" was entirely handled by javascript, this routing could not be handled by the server anymore, since the whole point of the paradigm was to use the server for nothing more than provide JSON or some other serialized data. As such, these SPA frameworks used what is called "client-side routing", which works the same way as server-side routing in that the address being shown by the browser is intercepted and looked up in an internal structure and the result is used to request some JSON to the server using asynchronous requests. The server will also most likely route internally, so there are two levels or routing.
Even though SPAs have been ironically abandoned for the past three or four years, web frameworks still use client-side routing for one reason or another, usually to avoid the "empty page" problem when navigating between two actual pages.
Client-side routing is the cause of the problem at hand, i.e. the use of BigInt inside Next.js. The example of routing used above,
https://domain.tld/accounts/1, is an instance of "dynamic routes", that is, a route, or path, in which one or more elements are not known until the browser actually requests it. In the example's case, the dynamic part is the 1, as it can also be 2, 100 or even a string representing the account's name.
Because of this property, it is possible to create a route
/some/path/resource.json that serves HTML (maybe showing the "resource.json" file) instead of JSON.
That in itself would not be a problem for server-side routing, but in client-side routing the browser does not perform a real navigation; instead, the address is changed by a script and a new entry in the browser history is pushed again by a script. Therefore, as it was the case in Next.js, certain dynamic routes can confuse the framework ending up with an element in the browser history that should've not been there, or the lack of a navigation when it should've been there.
In the specific case of Next.js, this confusion was solved by employing a Bloom filter for known static routes and a Bloom filter for known dynamic routes. If the route entered in the address bar or requested by following a link is part of one of these two set, then the browser will "navigate" towards the requested page, otherwise it will treat is as an asynchronous request to be handled in the background.
In the broken Next.js version, these Bloom filters were handled using a third-party library which used BigInt internally.
In conclusion of this wall of text: web framework are madness and single-page applications are madness on top of madness and trying to recover from this madness created even more madness.