So after some digging into NoScript's settings, I found some settings for something called "Cross-tab identity leak protection". Googling this led to a tor project issue Targeted Deanonymization via the Cache Side Channel. This seems to be a recently-added feature of NoScript intended to protect against a new de-anonymization attack. However, the attack seems to be of concern only for a somewhat niche threat model.
The attack relies on a cache-timing side channel, and the ability to share a resource with only a specific user on websites like Twitter, Google etc. to uniquely identify a target. From the website of said attack:
The attack builds on a leaky resource attack by using CPU cache side channels instead of cross-site leaks. In this way, the range of attack scenarios (i.e., affected browsers and resource-sharing services) is considerably larger.
The attack consists of two phases, setup and execution. In the setup phase, the attacker uploads a resource to a resource-sharing service, and then binds it to the victim’s identity. There are two approaches to perform this binding. In the sharing-based approach, the attacker privately shares the resource with the target (e.g., by using the victim’s email address or user ID with the service). In the blocking-based approach, the attacker makes the resource public, and then blocks the target from viewing any resources owned by the attacker. Next, the attacker embeds this resource into an attacker-controlled webpage.
In the execution phase, the attacker causes the target to visit the attack page (steps 1 and 2). As the target’s browser renders the page, it makes a cross-site request for the embedded resource to the sharing service (steps 3 and 4), passing the user’s authentication cookies. The response of the sharing website to this request depends on the target’s identity. With the sharing-based approach, the response to this cross-site request contains the shared resource if the user is the target, and an error otherwise (step 5). With the blocking-based approach, the opposite happens – the response contains an error for the blocked target, and the shared resource for other users.