You are focusing solely on the M and forgetting VP. If something isn’t a Viable Product then it isn’t a Minimal Viable Product.
You could create an MVP as an “experiment”, but it can’t be synonyms because not every experiment is even a product or a viable product and thus not at all a MVP.
If you're saying "before you release it, it has to be believable as a product" - I think I basically agree with that, and for sure, that's a subset of the total things that might be "experiments" (because you can experiment with individual features, and stuff like that).
I suppose there are two ways of reading the word "viable", either "does this look sufficiently like a product?" or "is a product with this basic concept likely to thrive in the marketplace?". I think too many people focus on the former and not the latter.
As someone who kept throwing out MVPs every few weeks to painfully discouraging indifference, the term "experiment" finally started to make sense - each attempt kept missing a leap-of-faith assumption being tested, so each failure was discouraging instead of enlightening/iterative.
I think first time startup founders incorrectly assume building an MVP is like logically assembling a lego set (one best practice feature + research + user feedback guarantees people using your MVP more than once). When that logic fails, it's a heavy hit mentally.
For example, sure you know that people pay for babysitters - but can YOU get people to pay for babysitters? Pretty sure that breaks all viability if false no matter how fancy the product, so might be a good starting point designing the "minimal" part of your experiment. Educational literature might benefit from less semantics about definitions, and more teachings about what a good MVP attempt #1 looks like.
A prototype is an experiment - confirming an idea works.
I think you’re conflating the two.
An MVP is about answering questions about end-user value. "I can make a thing, but is it valuable in the way I think it will be?". Absolutely that needs to be working software being used by customers, but crucially it needs to be the smallest increment you can get away with to confirm that the bigger "version" is worth developing.
This is where I disagree with the post: months, or years, to develop an MVP is just too long. That's an actual product cycle. If you factor in the cost of a couple of engineers or something, that means an MVP is a minimum 6-figure dollar investment.
Where I do agree is that an MVP should probably be morphed into the full product, rather than things be thrown away. But the whole idea of "MVP" as a singular rather than plural concept I think is wrong too; that's a lot longer argument though.
So a cupcake might be a suitable MVP, but you're either trying to confirm the basic flavour is fine (so single layer is OK), or maybe the combination of flavours is fine (multiple layers plus icing?) or maybe the overall look/design of the cake (in which case a cupcake is wrong, you need at least one large layer, but maybe's it's a sponge rather than fruitcake because that's easier/cheaper)
If you already know in some detail what the "final product" will be, then there's not a lot of point doing an MVP. The MVP is there to learn about what the final product should be. It's not supposed to be a go/no-go test on whether the final product is correct.