Thank's for your reply.
I wish you good luck with refactoring and hope to see this features in feature releases.
Can you provide a little bit more information about solution that I can do right now, please?
Do I need to do some specific actions with mkdocs.yml? Because just fill versions.json and create expected filesystem layout seems to do not work.

What I did:

versions.json

[
  {
    "version": "0.2",
    "title": "0.2",
    "aliases": []
  },
  {
    "version": "0.1",
    "title": "0.1",
    "aliases": []
  },
  {
    "version": "0.3",
    "title": "0.3",
    "aliases": []
  }
]

docs files layout

./docs
├── 0.1
│   ├── tab1
│   │   ├── side1
│   │   │   └── index.md
│   │   ├── side2
│   │   │   └── index.md
│   │   └── side3
│   │       └── index.md
│   ├── tab2
│   │   ├── side1
│   │   │   └── index.md
│   │   ├── side2
│   │   │   └── index.md
│   │   └── side3
│   │       └── index.md
│   └── tab3
│       ├── side1
│       │   └── index.md
│       ├── side2
│       │   └── index.md
│       └── side3
│           └── index.md
├── 0.2
│   ├── index.md
│   ├── tab1
│   │   ├── side1
│   │   │   └── index.md
│   │   ├── side2
│   │   │   └── index.md
│   │   └── side3
│   │       └── index.md
│   ├── tab2
│   │   ├── side1
│   │   │   └── index.md
│   │   ├── side2
│   │   │   └── index.md
│   │   └── side3
│   │       └── index.md
│   ├── tab3
│   │   ├── side1
│   │   │   └── index.md
│   │   ├── side2
│   │   │   └── index.md
│   │   └── side3
│   │       └── index.md
│   └── tab4
│       ├── side1
│       │   └── index.md
│       ├── side2
│       │   └── index.md
│       └── side3
│           └── index.md
└── 0.3
    ├── index.md
    ├── tab1
    │   ├── side1
    │   │   └── index.md
    │   ├── side2
    │   │   └── index.md
    │   └── side3
    │       └── index.md
    ├── tab2
    │   ├── side1
    │   │   └── index.md
    │   ├── side2
    │   │   └── index.md
    │   └── side3
    │       └── index.md
    └── tab3
        ├── side1
        │   └── index.md
        ├── side2
        │   └── index.md
        └── side3
            └── index.md

mkdocs.yml tried with extra.versions.provider: mike and without:

site_name: My Docs
theme:
  name: material
  features:
    - navigation.tabs
plugins:
  - search
  - offline

And I see no version-selector

Yes, the provider mike has to be set

You can see the structure of files in the deployed example here:
https://github.com/mkdocs-material/example-versioning/tree/gh-pages

The first level of navigation is transferred to this selector (as happens when you enable navigation.tabs), then the second level of the directory structure is transferred to the tabs, then sidebar and etc.

The idea you had is already kind of built-in, but there is no transferring and adjusting of these things at runtime, but instead correct file placement before and after build is necessary.

The issue in your case is that you're putting each version inside of docs and they're a part of one single build process, one single navigation tree. And the expectation is that each version is a standalone site with a custom base url one level higher than the "true" base url. Let's assume that a single version has 100 pages, then you have 100 versions. This will quickly grow into a very unmaintainable slug if everything is a part of a single docs source directory.

Your idea with forking the i18n plugin to handle the versioning separation might be a good direction to take. However, keep in mind that the i18n isn't perfect and has limitations like lack of support for the blog plugin and in general has to do a lot of "juggling" to make other plugins work well in the "single context multi-build approach" for lack of a better terminology. Also it might keep the performance of the latest version steady, but it would still rebuild each version sequentially, so it would also be a slug in CI.

The projects plugin might be better, but it follows the rules of keeping the contexts of each "project" separate, but at least it builds them concurrently.

So to reiterate, the simplest way to set up the versioning would be to use a custom versions.json, but you also have to set up a bit of custom logic to build separate docs for each version and put them in the right place. You could make use of the mkdocs.yml INHERIT functionality and use multiple configuration files that each share the same plugins, but only change the base config and version number. Or use a single mkdocs.yml but use a hook / wrapper launch script to change the docs_dir based on some criteria.

Also mike is a wrapper for MkDocs itself, it implements a mike deploy command, so it's probably the same as mkdocs gh-deploy, which does a mkdocs build first and then sends the files to the remote git repository. I don't see a mike build command, but it should be possible to modify it to only build the docs without any deployment.

Also mike is a wrapper for MkDocs itself, it implements a mike deploy command, so it's probably the same as mkdocs gh-deploy, which does a mkdocs build first and then sends the files to the remote git repository. I don't see a mike build command, but it should be possible to modify it to only build the docs without any deployment.

mike deploy simply runs mkdocs build. The 'secret sauce` is the parts where it creates a commit with the new documentation, but at a different location.

You can see that it just builds in the deploy function in driver.py:

            mkdocs_utils.build(config_file, args.version, quiet=args.quiet)

The line is wrapped by a few context managers however:

    with handle_empty_commit():
        alias_type = commands.AliasType[args.alias_type]
        with commands.deploy(cfg, args.version, args.title, args.aliases,
                             args.update_aliases, alias_type, args.template,
                             branch=args.branch, message=args.message,
                             allow_empty=args.allow_empty,
                             deploy_prefix=args.deploy_prefix,
                             set_props=args.set_props or []), \
             mkdocs_utils.inject_plugin(args.config_file) as config_file:

• The first one, handle_empty_commit() is there to add a 'are you sure' confirmation step if everything below it resulted in an empty commit.
• The last one, mkdocs_utils.inject_plugin(), auto-injects mike into the plugins configuration.
• The middle one is the magic one, it is defined in commands.py and after some metadata maintenance it copies the newly built site into a version-specific location for deployment:

    destdir = os.path.join(deploy_prefix, version_str)

    # ... snip ...
    
    # Let the caller perform the build.
    yield

    if alias_type == AliasType.redirect and info.aliases:
        t = _redirect_template(template)

    with git_utils.Commit(branch, message, allow_empty=allow_empty) as commit:
        commit.delete_files([destdir] + alias_destdirs)

        for f in git_utils.walk_real_files(cfg['site_dir']):
            canonical_file = f.copy(destdir, cfg['site_dir'])
            commit.add_file(canonical_file)

There is a bit more to it but where it says yield the context manager setup ends and control passes to the mkdocs_utils.build() call in driver.deploy(). Once the site is built, control returns to the if alias_type ... line, after which mike creates a commit that replaces the destination directory with a full copy of the site.

The rest of the function deals with different types of redirects / symlinks, updating the version metadata file, and ensuring the .nojekyll file exists.

This approach makes it possible to only build the current version of the site, never needing to touch old versions, which, as the documentation states, could have been built with older versions of mkdocs that no longer can be re-created today.

The version integration with the theme is handled almost entirely in the plugin on_files() handler, by including theme-specific CSS and JS files. The only other thing it does is adjusts the site_url to append the version specifier.

If you can't see a version selector, I'd look a the relevant themes directory for the javascript that loads the versions.json file and try to figure out why it fails to load that data.