Well, it sounds like packaging recipes are the way to go here. Basically, packaging recipes can automatically create Ubuntu source packages and upload them to a PPA whenever a bzr branch on Launchpad changes. The online documentation is pretty good, but I'll give a couple of examples...
First, you specify a branch to track (for example, lp:gtk3) and then add a command to nest your own Debian packaging branch into that branch. Take a look at this recipe I created for daily builds of Inkscape.
# bzr-builder format 0.4 deb-version 1:0.48+devel+{revno}+{revno:packaging}
lp:inkscape
nest packaging lp:~inkscape.dev/inkscape/debian-packaging debian
This recipe creates an Ubuntu package each day using the latest upstream source for Inkscape, but copies customised Debian packaging instructions from the lp:~inkscape.dev/inkscape/debian-packaging branch into a subfolder called "debian".
The packaging recipe page on Launchpad allows you to specify which PPA to automatically upload your packages to. In our case, it is uploaded here.
As an alternative approach, you could base your recipe on an existing Ubuntu package rather than directly on the upstream source. For example, lp:ubuntu/gtk+3.0. You'd then need to create a branch of this code, and commit any modifications you require. Let's call it lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build, for example. You would then create a recipe to automatically merge your changes rather than nest packaging instructions. The recipe would look something like:
# bzr-builder format 0.4 deb-version {debversion}+{date}
lp:ubuntu/gtk+3.0
merge my-custom-build lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build
This recipe, therefore automatically builds a custom Ubuntu source package and uploads it to your PPA whenever there is a change in the official Ubuntu package.
If you take this "merge" approach, then you have two options for applying your patches. Either you'd just edit the upstream source code directly in your branch and let bzr take care of merging it, or you could create patch files inside the debian/ folder using quilt. Each has its own advantages/disadvantages. The former approach is a bit smarter... if one of your patches is adopted by the upstream developer, then the merge will usually still work and the Ubuntu package will build OK. The latter approach lets you handle your patches using the standard Debian-based approach of keeping packaging code separate from upstream code... however, if the upstream developer adopts one of your patches then quilt won't be able to apply the (duplicate) patch and the package will fail to build.
Is there no backwards compatibility between repositories?
Yes, there is but to some extent. For Ubuntu versions you can use repositories through the versions that are not end of life but mixing releases is not recommended.
1 problem you will run into is when there is a big change in the default software. Ubuntu went from Gnome to Unity so any tool depending on the old style will be buggy or completely useless. That probably includes that Mint Menu.
If someone stops maintaining a repository, is it basically dead and useless?
Ubuntu will move the default repositories to an archive so these are still usable to Ubuntu users. How others deal with this is up to them. Personal archives tend to be available on launchpad for all releases (even those end of life).
Best Answer
I recommend the PPA I created for this. It contains a patch I created that adds an appindicator to it, since the old systray is no longer supported in Ubuntu. https://launchpad.net/~stefansundin/+archive/truecrypt
The version is 7.1a, and I do not intend to update to 7.2 because it has less functionality.