As I understand, there is no 'edge detection' in MSAA. You're simply rendering geometry using slightly different camera angles, and average over the results. If the vertex disappears in the middle due to alpha channel, FXAA / MLAA / SRAA will stumble upon edge detection, but MSAA will simply do nothing.
What you describe is kiiiiinda sort of close to what TAA does (though it does it over several frames which is why when you stay still the image becomes very smooth but when things move they are a bit sharper). Though "TAA" isn't really a single method, it is more of a general approach and every implementation is different - kinda similar to SSAO.
MSAA is basically a modification of SSAA. SSAA takes multiple samples for each pixel (taking samples = checking if a pixel is inside or outside a triangle and if inside, calculating the final color) and averages the result. Essentially it is like rendering a picture at a high resolution, e.g., 2000x2000 and scaling it down to 1000x1000 (this is 4xSSAA because it uses four samples -2x2- per pixel).
MSAA does that but it only uses multiple samples near the triangle edges (there is no edge detection since the GPU already knows where the edges are) and only one sample for pixels that are "inside" the polygon. This allows it to be faster than SSAA while still producing smooth edges.
The main issue with this is that anything with high contrast inside the polygon only has one sample taken so it can have jaggies. Note that this isn't just about pixel shaders or even modern engines (though pixel shaders often are used to add normal mapping and sometimes even parallax mapping which essentially acts as if you have more geometric detail without actually having it, so it makes the issue more visible). You could have the same issue with, say, a game using one or two big triangles with a texture with a checkerboard and nearest point filtering: jaggies will appear where the checkboard changes from black to white because even though you are using MSAA, it is only applied at the edges of the triangles and not inside the triangles where the checkerboard changes from black to white.
One way to avoid this is to do what i wrote previously and define a minimum number of samples per pixel. This is trivial to do though it does make rendering the scene heavier (and MSAA itself isn't light either). On the other hand this could be applied per material so you could only use it for problematic materials that show a lot of shimmering.
Modern GPUs also have introduced variable rate shading which essentially allows shader calculations to be shared among nearby pixels - ie. the opposite of MSAA. I haven't tried it myself (i do not think my GPU even supports it) but it could probably be used to counteract the performance penalty that a minimum number of samples per pixel adds. Though that is a guess TBH.
It is broken somewhere in the middle, especially when using deferred lightning / shadows or fancy shaders. You want to support older GPUs, but at the same time you don't want to design separate renderer for them, so MSAA option is either not available or broken.
FWIW this was only an issue back in the midlate 2000s when GPUs didn't support multisampled render buffers, but nowadays it isn't really a problem and hasn't been for a while (actually it wasn't even when i made that engine, i think even the ATI X1950 my old Athlon64 has could do it).
This video shows an engine i wrote back in 2012 and has deferred shading, SSAO, 4xMSAA and contact hardening soft shadows (which is what the video mainly focuses on).