Is it possible/acceptible to take over an existing module's name and replace it with a different module?

Yes, this possible and acceptable.

Please see this page: Taking over unsupported (abandoned) projects, there is section titled "Taking over an obsolete project's namespace" that is relevant to your case.

Please note that you still need to comply with the full procedure:

1. Start out by posting an issue in project's issue queue, requesting ownership.
2. Contact the present owner (e2thex) via the "Contact" tab on their profile page to make them aware of the issue.
3. Record that you've tried to contact the owner in the issue summary.
4. If the owner replies and OKs the transfer, move the issue to the Drupal.org project ownership issue queue.
5. If the owner don't respond, move the issue to the Drupal.org project ownership issue queue 14 days after you tried to make contact.

Something to note with the collections module, since there are a few sites using it, the existing code should be maintained. The fact that it is a d7 module helps, as well as only having 25 sites.

Nevertheless, make sure the old issues and releases remain the same. You should also make a note that the 7.x-1.x version is an entirely different module and there is no upgrade path to the new version. Something similar was done with the event module: https://www.drupal.org/project/event

I think that shall be fairer to say that the "existing code should be preserved". With no updates in 9 years, there is obviously nobody around that cares about maintaining the Drupal 7 branch of this baby.

For the record: Someone who takes over an abandoned module's namespace is under no obligation to maintain the legacy branch(es).

The preservation of the code in the legacy Drupal 7 branch is automatically taken care of by git.

However, unlike the obsolete Drupal 5 Event module, Drupal 7 is still a supported version of Drupal. In the unlikely case that somebody shows up and offers to maintain the Drupal 7 branch, any owner of the Drupal 9+ branch should grant access to that person as a maintainer/co-maintainer.

But I agree that is important to preserve old issues and releases in their present state They should only be removed when usage reaches zero or when Drupal 7 reaches EOL (whatever comes first), and to also make it clear on the project page that the Drupal 7 and Drupal 9+ branches are entirely different, and that no upgrade path exists.

So far, daggerhart has not proceeded with the steps necessary to take over its namespace, so all this is a bit hypothetical.

The only issue I could see with taking over a project to change its purpose, and which should eventually be resolved in the code that reports project updates, is for users who are using the old module and that could get an update warning that would make them install a completely different module.

In this case, the last commit has been done 9 years ago. I believe we could not add Don't reuse a project namespace when the last commit has been done less than 10 years ago. in the project taking-over "rules."

apaderno wrote:

The only issue I could see with taking over a project to change its purpose, and which should eventually be resolved in the code that reports project updates, is for users who are using the old module and that could get an update warning that would make them install a completely different module.

AFAIK, that's not how it works. If somebody is using a Drupal 7 version of an extension, and its namespace is taken over by somebody that creates a different branch (e.g. Drupal 9) for some other purpose, they'll get no warning or other type of message. Only if the branch they've got installed gets updated, or this release gets pulled (usually for security reasons), they will be told to update or uninstall.

To "fix" this non-problem, apaderno, suggested that we add this provision:

Don't reuse a project namespace when the last commit has been done less than 10 years ago.

This is, IMHO, unnecessary and unwanted.

First: The 10 year limit suggested is rather arbitrary. No major Drupal version, except Drupal 7, has lasted 10 years. Drupal 7 was released in 2011 and projected EOL is in 2023 (that is 12 years, and it is a very special case). I think that the transfer of the namespace for an abandoned project whose most recent version that is past EOL (as happened with the Event project mentioned in comment #3) is unproblematic and there should not be a X years embargo imposed on such transfers of namespace.

Second: Proliferation of namespaces for extensions hosted Drupal.org is undesirable. Forcing a new extension to select an awkward namespace just because the wanted namespace is squatted upon by some long dead project that just has been abandoned for 9 (as opposed to 10) years is not right.

To conclude: I think the procedures we already have in place for this is, adequate.

Requests for transfer of namespaces are rare. And before anything can happen, the supposedly abandoned project has to go through the steps to make it officially declared "Abandoned" by its present team. We are never going to transfer the namespace of anything that actually has a team supporting it behind it.

The new namespace must fork a new branch, which automatically will preserve the abandoned branch until eternity, or if until someone comes along and offers to support it – whatever happens first.

I am -1 on imposing any kind of embargo or time limit on transfer of namespaces. Our present procedure for doing this has worked well in the past, and shall continue to do so.

AFAIK, that's not how it works. If somebody is using a Drupal 7 version of an extension, and its namespace is taken over by somebody that creates a different branch (e.g. Drupal 9) for some other purpose, they'll get no warning or other type of message. Only if the branch they've got installed get updated, they will be told to update.

Sorta -- there is an indicator showing that the next 'major' version of a module is available, but is more informational than a warning. However, if you mark something as unsupported (as the maintainer would probably do for 7.x-1.x), it would light up red flags that they need to uninstall or upgrade that module. Seeing a 7.x-2.x version as an option would be bad IMHO, because its not the same thing.

I'd tend to agree that marking a timeframe is probably not advised. However, tracking vs major module versions could be. This is also changing with the community moving to semver. Future versions in the same namespace could be entirely different with a new major branch. However, we need to be careful here. Maybe an option is having core NOT show the next major version if its over 2 major versions away: (IE: old version is 1.0 and new version is 3.0, with no 2.0 release, users wouldn't see a suggestion to upgrade to 3.0)

For the current situation, I'd suggest the following, assuming the original creator goes through the abandoned projects process and is granted access:
1) Keep the existing maintainers for the 7.x-1.x branch, and don't change the supported status unless there comes an unpatched security bug.
2) Post on the page that the 7.x-1.x branch is entirely different from the current version.
3) See if the requestor is willing to only make a semver (Drupal 8.9+) branch. If there is no new Drupal 7 version this avoids issues with the existing D7 sites upgrading to an entirely different project.

there is an indicator showing that the next 'major' version of a module is available, but is more informational

Thanks for the heads up!

If this turns out to be a real problem, we could probably implement a project tick box that says "Different purpose - don't flag this upgrade to older major versions" for the maintainer to tick when appropriate. But I think that making the situation clear on the project page (item #2 on your list) is going to be sufficient.

However, if you mark something as unsupported (as the maintainer would probably do for 7.x-1.x), it would light up red flags that they need to uninstall or upgrade that module.

I think we're talking about different things. Setting Maintenance status for the project to "Unsupported" have no consequences on the client side. This setting cover all branches so if at least one branch is supported, it shall not be set to "Unsupported".

However, there is another setting that is per release on the "Administer releases" page, that let you pull a single release. If you untick "Supported" for a release the client side light up with red flags like a Soviet military parade. This is very upsetting to users, so the established practice among site moderators it to not do this unless there is a know security vulnerability.

I agree with your list. We don't instruct the new owner about these things now. However, my impression is that this is how things usually is done. E.g.: New owners keep the old team around unless they behave disruptively (a while back, we had someone reversing all new commits, yelling "this code is mine, mine, all mine"). And I think almost everybody starting a new branch for Symfony-based Drupal uses semantic versioning. However, we may think about creating some guidance.

Quite the opposite. I said I believe we could not add a restriction for taking over a namespace basing on when the last commit was done.

I believe we could not add Don't reuse a project namespace when the last commit has been done less than 10 years ago. in the project taking-over "rules."

I agree we should be extra cautious in these cases, but not in the case a project hasn't get any commit in the past nine years, although I can also see cases where no commit is necessary, but the project cannot be considered abandoned.

Anyway, this was a support request opened by a user who wanted to know if taking over a project to create a different project was possible.
That part has been addressed. To change how requests to take over a namespace are handled, we need a different issue.