The problem
Let's face it, with the velocity of major version upgrades in Drupal having increased a lot since Drupal 9, many projects - both themes and modules - do not yet have releases for Drupal 11, or even Drupal 10 for some of them, although they may have automatic compatibility patches / issue forks ready to be committed for months.
But, alas, just because they do not declare Drupal 11 (or 10) compatibility in their composer.json (or they don't have one yet, looking at you Bartik), composer require with a patches clause won't work because Composer checks for compatibility without the patches. So how can we use all that perfectly ready code that doesn't have a correctly labeled release ?
The classic solution: forks
External forks
For about a decade, one solution has been to use a project fork. You could fork a Drupal project on a Github / Gitlab repo of your choice, declare it in the <repositories> section of your composer.json, and adjust the release version for standard Packagist releases, or even plain Git versions.
That was a reliable solution, but with two related issues: the need to even understand that mechanism, and the fact that the versioning would no longer be generated by http://packages.drupal.org/8 aka the Drupal Composer facade, meaning your forks had to include a correct composer.json file, which does not always work as one would expect due to some magic in the facade, which would generated some exotic release identifier based on the extensions's *.info.yml files.
Plus, obviously, the complete disconnect between the original and fork, meaning a need to regularly sync them by hand. Useful, but not great.
Enter Gitlab-based Drupal.org: issue forks
At some point, though, Drupal git hosting was eventually migrated to Gitlab, and with it appeared Issue forks.
For all the naysayers not even accepting that this could exist, it really means that with for each issue on which a patch would previously have been generated, and rerolled before being eventually merged, there would now be a completely independent fork, persisting after the issue was closed. And that suddenly made forks much more practical : at that point, you would still update the <repositories> clause in the composer.json file for your project, but that would now point to the Drupal Gitlab fork for the issue for which the patch was to be applied.