Support composer_manager AND drupal-composer/drupal-project with contrib module
Here are the conclusions I will follow for the CFR module package.

I am writing this as guidelines for module maintainers.

The steps may look different for other module packages with a different structure.

Start a new major version.

If the existing version of the contrib module requires composer_manager to work, supporting an alternative method might come with backwards-compatibility-breaking side effects. If this is the case, a new major version should be introduced.

Use the 'alternatives' module.

The alternatives module allows to replace one dependency with another.

In the *.info file:

dependencies[] = composer_autoloader
alternatives[composer_autoloader][] = composer_manager


This means: If 'alternatives' and 'composer_manager' are enabled, then the module in question can be enabled without enabling 'composer_autoloader'.

Depend on composer_autoloader

Let your modules, or one of them, depend on composer_autoloader, but add the alternatives[composer_autoloader][] = composer_manager as mentioned above.

Doing this in a subdirectory module causes the metapackage to require drupal/composer_autoloader.

Additional composer.json file at the top level

Why?

Composer manager will look at composer.json files per (sub)module. If the root dir of the module package contains a composer.json, but no module exists in the root dir of the module package, this composer.json will be ignored by composer_manager.

On the other hand, the project_composer module responsible for packages.drupal.org will extract metapackage information from the *.info file in a subdirectory module, but ignore composer.json files for modules in subdirectories. 

Unlike composer_manager, it does look at the main composer.json in the package root dir, even if there is no module in this place.

How?

Put one composer.json at the top level directory of the module package. This has to require the 3rd party libraries from every submodule contained in the module package.

Keep the submodule composerjson files in place.

Replacement composer_manager for the transition.

Goal: Transition from composer_manager to composer_autoloader + drupal-composer.

Problem

If the modules were previously installed with composer_manager and now we want to use composer_autoloader, we are in a bit of a pickle:


At least one of the two dependencies must be enabled at any given time, to allow the dependee module to remain enabled and the 3rd party libraries to be autoloaded.
Downloading both with drupal-composer is not possible, because composer_autoloader declares a conflict with composer_manager in its composer.json.
Assuming we would find a way to download both composer_autoloader and composer_manager at the same time, having both enabled would be possible but would perhaps cause weird behavior due to duplicate vendor directory and duplicate autoload.
Updating code and database at the same time is not possible. We need to call drush en and drush dis, or do the switch via hook_update_N(), in the new codebase.


Solution

Let the site builder create a dummy / placeholder version of composer_manager in sites/all/modules/custom/composer_manager.

The only thing this would do:
- a hook_boot(), which would check if composer_autoloader exists, and if not, it replicate the behavior from composer_autoloader.
- a hook_uninstall() to replicate uninstalling the regular composer_manager.

Then use a hook_update_N() to enable composer_autoloader and disable + uninstall the placeholder composer_manager module.

Perhaps such a placeholder module could be provided on packagist, with an obfuscated name to prevent the conflict with composer_autoloader.