So, I was having this issue as well, and I did find a solution that worked for me (though I understand it may not work for everyone). I hope others can at least gain insight from how I went about solving my issue.
In my case, I’m making a 3rd party plugin using C++, and was having the issue described by some i.e. whenever I created a blueprint derived from a C++ class, it worked initially, but failed the next time I rebuilt the editor.
Non-solutions proposed previously: deleting the binaries folder (I didn’t even bother with this one, I’m not doing that every time I load the editor), disable live coding (I’m on Linux and currently this isn’t even supported, so there’s nothing to disable), creating a new class and copying over my code (that’s not a solution, it’s just pushing the problem further down the line). Tracking the naming of a C++ class using PipeRift (I never re-named anything so this shouldn’t be the issue).
Solution that worked for me: in my .plugin file I changed
"LoadingPhase" : "Default"
to
"LoadingPhase" : "PreDefault"
Why I believe this solved the problem for me: the blueprint becoming invalid probably means that at the time when the referenced blueprint gets loaded, the corresponding plugin (and hence the C++ class) has not been fully loaded. The blueprint then gets marked as invalid. It also makes sense why even if it’s invalid, remaking the blueprint works as well, because by the time the editor is fully loaded the classes are all fully loaded, and so there’s no issue.
So, overall the issue is most likely with the loading of your C++ class. If you are writing a plugin this can be controlled with the .plugin file. If you are not writing a plugin hopefully this sheds some light.