Adding this mod to an existing game makes all affected machines loose their recipes.

Wow! Here comes Optera! I take the opportunity to say thanks to your great mods.

Hmm... I have thought of that when I first create this mod. I expected a simple FOR loop scanning all machines on map...
But there are several factors that made me realized a migration is not as trivial as I thought.
1/ Scanning all machines on the map can be a slow process, even if it is only done once (supposedly, see below) on migration.
2/ When players tuned even a minor setting in "Machines using scaled recipes" and/or "Exclude recipe", the scanning/replacement have to be redone to keep consistency. So not only once. Then it is no longer the original "upgrade once" logic in the migration script, so starts to get complicated...
X/ For recipe replacement, I found LuaEntity::get_recipe() & LuaEntity::set_recipe(recipe) is the function to be called. I guess it is not a problem so does not count to the list.
3/ When players "downgrade" the recipes, "reverse migrations" have also be done to all machines too, to keep consistency to the new settings. This will cause the logic in migration script even more complicated.

If it were just a simple upgrade once migration, I would have already implemented that.
But for the complexity mentioned above, I am not sure if it is a good idea to implement that... Maybe I will try that when I can sneeze out some free time.

Yes, here I come.
I was about to write a "simple" mod to create bulk recipes to improve performance for those annoying 0.5s recipes, when I found you already did most of the work for me, thanks.

I'm not sure why you'd have to do multiple runs.
You can't tweak recipes during runtime, by the time migrations run everything from data stage is finalized.

I haven't delved into your code, but basically it should be as "simple" as
1) compiling a lookup table of old-recipe = new-recipe
2) find all machines affected by the mod
3) check the recipe on each machine against the lookup table and update where needed

PS is there a way to make your mod only affect 0.5s intermediate recipes and have it keep the original recipe alongside the bulk recipe?

The problem comes from I cannot know which state the save game is, when the migration script is being triggered. There can be several cases:
1/ This mod is not installed before. The simplest case. Just convert every recipe to the scaled recipe, in the included machines. (Like what you mentioned.)
2/ This mod is already installed when the game is saved. Migration is triggered by changing of mod option settings, be it the list of included machines or the list of included recipes are being adjusted. It is logic-wise difficult if the two lists are purely expanded, purely reduced, or mix of both. So have to handle each machine-recipe combination case-by-case. It can either be:
2A/ Machine not in list, recipe using not in list: No changes needed.
2B/ Machine in list, recipe using not in list: Upgrade recipe!
2C/ Machine not in list, recipe using in list: Downgrade recipe!
2D/ Machine in list, recipe using in list: No changes needed.
2E/ The mod(s) involved in the machine or recipe is/are being disabled: Skipped / No changes needed. (I am not sure if disabling other mods will trigger migration. But added this case for safety.)

With case 1 only, migration is done once only. But all the things under case 2 is the source of complexity, as said in my former reply.
Anyway, after sorting this pseudocode out, it is not as complicated as I once thought. Maybe it worth some hours to finish and test it out.

========

Yes, I could add a threshold (as an additional option) in recipe time, where only recipes faster than that will be scaled.
This should be easy to do in my code.
(This was actually also my first thought when creating this... I planned to modify every recipes below 10s to overcome the 1 crafting per tick game limitation. But with my Schall Machine Scaling already working, I end up the current solution instead: Clone and scale up every recipes for specific machines only.)

========

Yes, I could add another option allowing the included machines to also use the original recipes. The logic will have to be expanded a little bit, to coexist with current option. But I would say it is easily doable, just need some time to test it out.
I have not done any analysis about recipes time range. I hope they will not clutter the recipe selection menu too much.
And since they coexist with original recipes in the same menu, perhaps I should add a small subicon to make them stand out from original ones? Do you have any suggestions to me?

Running a full migration whenever startup settings are changed, e.g. machines being added, seems too much work.
I only want case 1) mod hasn't been installed before migrate old recipes to new ones.

If you allow old and bulk recipes to coexist not even that might be required, I could just gradually stamp updated blueprints over my existing production lines.

About icons, yes an overlay with a number would be nice, but since you gave full freedom about the multiplier you can't simply slap a single layer with "10x" in the corner over existing icons.
You'd have to make layers from 0 to 9 and shift them around to write the numbers if you want to be that fancy.

Otherwise I'd just write a "x" in the bottom right or left corner. If you want an easy time doing that check my library, it already has a tested method for adding layers to icon or icons. https://mods.factorio.com/mod/OpteraLib

Alright, as I will implement the "coexist" option, so maybe I will just skip the whole migration thing. The new options worth more time to be spent on them IMO.

Maybe I will just implement a simple coloured "x" at one of the corners. This mod will clone only ONE copy of each recipe, so even without numbers won't confuse players. Merely just to distinguish them from original recipes.
In default settings on a vanilla style game can already multipliers ranging from 1 to 50. Some crazy mods may have recipes up to five digits. (Possibly up to 65535.) Would be difficult to make the display look clear and nice for both "2x" and "10000x", in such tiny icons.

Scientific notation never uses more than 4 digits. 100000 = 100k or 0.1M ;)

Just released 0.17.3, including the above-mentioned features.
BTW, there are things that are not as trivial as planned. For example, recipes cannot be chosen on furnaces.
If both original and scaled recipes are available to a furnace, it will "most likely" (to the ores I tested with) use the original recipes, so speed cap kicks in... So I have to add an extra option to exclude furnaces or alike to make that use scaled recipes only.

I am not proficient with graphics. Making new icons for 0.18 is not difficult, but doing that for all my mods really takes time...

With furnaces having multiple recipes for the same input makes no sense as they pick the first recipe they find which always will be base.
Finding furnace recipes however is really easy: recipe.category == "smelting"

I do not want to hard-coding the category, since a lot of overhaul mods have their own smelting category.
And rather than on "recipe category", it is the "machine type" that recipes cannot be selected. So I would rather use the current solution (option "Machines using scaled recipes only"), for users to freely set which machines do that.

Never mind, I was wrong, the category can be anything.
I was looking at how I deal with it in ReStack and just remembered I don't support mods defining categories not in base.

To fully support mod categories you'd have to parse all type = "furnace", build a table of crafting_categories, then check recipes against that table.

Just updated my mods for 0.18. Now finally have time come back to this.
You may be right for scanning all entities under data.raw.furnace. But since the current way (by options for name pattern matching) is working and no one is complaining yet, so I think I will just keep it for the moment.