Hello,
I'm not aware of any published best practices regarding MDG Technologies. It's more along the lines of working it out as you go along and try to understand why what you tried didn't work. This forum is really your best source for guidance.
The main drawback of keeping the technology source model in [one of] the same project as end-use models is simply safety: someone might accidentally change or delete things, or inappropriately use elements from the technology source model in some other model. It also makes it possible for the modellers in that project to create new versions of the same technology, because they have access to the source model. If the source model is in a different project, they can't.
Whether these are concerns in your case, well that all depends. If it's only you then it probably doesn't matter, but you might get stuck on something and rage-delete the project, with unintended consequences. In general it is good practice to keep to one (possibly large and complex) goal for the modelling in each project; MDG technology authoring is one such goal, and I for one prefer keeping that stuff separate.
When you start working with scripts, you will find that those are much easier to manage if the authoring is done in a separate project. Otherwise it gets hard to see which is the source version of the script and which is the deployed version. Not impossible or anything, it just makes life that little bit harder.
The case you describe where you want to reuse an enumeration in both the source and target projects is in my opinion not strong enough, and in fact bad practice. A technology is such a fundamental underpinning of a model that if you make changes to it along the lines of redefining an enumeration (which can include adding and deleting values), you don't want that to automatically affect existing models. Such changes must be carefully considered, not auto-cascaded (and EA doesn't support such auto-cascading anyway).
Remember, the enumeration you use in your technology source model is not part of the technology. The technology instead contains a tagged value definition with those same values, but that is not the same thing (this sentence is Paolo bait). If you want to reuse a tagged value definition, that's perfectly doable but you'll have to create it as such in the source project and pass it along explicitly (Tagged Value Types in the technology creation wizard). You can use a tagged value definition instead of the enumeration in your source project, and the resulting technology will be identical.
MTS management is a bit of an annoyance, I agree. But if EA does not remember your MTS files, there is something wrong. It remembers up to 10 MTS files if memory serves, they're stored in the Windows registry under HKCU\Software\Sparx Systems\EA400\EA\MTS Recent File List. But perhaps you mean it doesn't remember the single most recent one and you're right, it doesn't do that.
The way to do shared development of a technology is to keep at least the MTS file, and preferably all the "published" profiles, on a file share. In addition, if you include search definitions in your technology, those must be managed because the source for those is in fact the user's %AppData%. EA does not provide any help with synchronizing search definitions between the members of a technology development team. But I believe that is the only gotcha; everything else works from a shared directory.
You could use a version control system, but the problem with that, as you've noted, is that paths are absolute. UNC paths are supported, but if you're using drive letters you need to synchronize those across the team as well.
If I may take a moment for a shameless plug, I have been working on an Add-In to help with MDG technology development, and the issues you raise are among those addressed in that Add-In. It doesn't fix everything, but it does make things easier.
I'm working on other things at the moment, but am expecting to release this before the end of the year. Won't be free, but won't cost much either.
HTH,
/Uffe
