Bitbucket: repatriating a fork back to where it was once forked from

I am hoping for some advice on how best to perform a particular bitbucket/git maneuver which will fork a repo back to a team from which it was previously forked.

Let’s call it Repo R, originally in the Untitled Projects project of Team T.

Some months ago, Repo R was forked to User U’s personal account, who worked on it for a number of months, while Team T did not. (So in theory, the current state of Team T’s languishing Repo R is contained in the history of User U’s Repo R, but maybe not.)

Now we want to fork User U’s Repo R back to Team T, as User U is no longer working on it, and Team T will be. (It might have been better for User U to simply have worked on it under Team T, but water under the bridge.)

Now, we can’t just fork Repo R back to Untitled Projects, because its name will collide with languishing Repo R already there (I assume).

We don’t want to rename the repatriated Repo R, because it already has the name most indicative of what it’s for.

And we don’t want to delete languishing repo R, because it might turn out that repatriated Repo R is missing things or in some other way deficient, and we need to revert to, or at least consult, languishing repo R. Also would prefer not to rename languishing repo R, because that’s what it’s always been called.

So, my tentative plan is to create, in Team T, an “Obsolete Projects” project, move languishing Repo R in there, and then fork User U’s Repo R back to Untitled Projects.

(And possibly come up with a better name for Untitled Projects, more like Active Projects or somesuch.)

Is this plan sound? Is there something better I could do? Thanks.

[Edit responding to comments by @BartvanIngenSchenau and@scriptin]

I am averse to merging User U’s developments back into Team T’s languishing Repo R for a couple of reasons.

1. I’m wary of any changes User U might have made to their Repo R’s history, and whether that might collide with Team T’s Repo R if merged. I want to be sure that Team T’s Repo R as it stands is undisturbed.

2. We need to get a good look User U’s Repo R before deciding to move forward with that set of branches. There’s say 25% chance that we decide it was generally not the way to go, and really want to proceed from Team T’s older position after all. Having merged in User U’s changes, of course we could still ignore them, but they would be there as a distraction. But we only have limited time to access User U’s Repo R, so we need to move, copy, clone, fork it or whatever so we have a place to inspect and test it.