I did think of "maybe" possible solution for problem Number 1 on the list above.
Now, the problem had to do with when you switched perspectives while dematting and the sound stops. This is because the Source engine was written with a property that stated that when you move far enough away from a sound source, it will just be stopped. In this case: When switching perspectives.

Again, I have very little Lua scripting experience. Just a basic understanding of how it works.

One thing I noticed was that this issue never applied to flight mode, and this is because that flight sound is a continous loop of a short sound. When the Source engine cuts off the sound, the loop just repeats and almost seems like the sound never stopped. The demat sound is different because it's just one long soundtrack that is played once when the TARDIS demats. Since it isn't a loop, it could be cut off right in the middle and wouldn't continue until the sound instance was prompted again.

A possible workaround to this issue would be to apply the same principles of the looping sound.

To picture this, imagine you opened up the long demat sound in a program like Audacity. This is what it would essentially sound like:

Wurr...Wurr...Wuuuur...Wuuuuuuuuur...Wuuuuuuuur...Wuuur...

The sound itself is just a bunch is separite wurring sounds. Of course, you can't loop it like discussed because the wurring changes and get's louder. Instead, let's take the cutting tool in Audacity and seperate the "wurrs" into individual sounds, like Wurr1, Wurr2, Wurr3, etc...

1. Wurr...

2. Wurr...

3. Wuuuur...

4. Wuuuuuuuuur...

5. Wuuuuuuuur...

6. Wuuur...

Seperating this one sound into several separite sounds would be time consuming and a pain in the ass, but now we have an excellent advantage! Because we made individual sounds, we can write a simple script that would play these sounds in a timed sequence. For the sake of explanation, I'll simplify the concept of the actual programming language (Note: I'm going to use one of probably serveral time sequencing methods):

-Play Wurr1
-Wait (a) --"a" being the time length of the sound on the line above.
-Play Wurr2
-Wait (b) -- "b", again, being the length of the sound on the line before it.
-Play Wurr3
-Wait (c)
...and so on.

If the sounds were set up like this, when the Source engine cuts off one sound, the next one in the sequence will simply play and the cycle will just continue normally, thus solving our problem (in theory).

Now, I have another theoretical solution for Number 2. This one is a bit simpler:

Set the normal weight of the TARDIS to something realistic (Not ♥♥♥♥♥♥♥ 5000, Matt!). The script regularly dictates that when the specified key is pressed (R by default), it will toggle flight mode. In this script, just include a property modifier to set the TARDIS weight to 5000 when flight mode is toggled on, and when it's toggled off, it will set the TARDIS weight back to the original lighter weight. Simple! Right? We don't have to modify any formulas or create a whole new system for it, just apply the appropriate weight when needed and revert when it's not.

I can easily modify the weight, but keep in mind weight affects air resistance and stuff

I agree there should be a setting to change its weight. As the Doctor said in Flatline, it never lands with its true weight and he can adjust the "relative gravity."

Whoa, that just appeared Matt! Also doesn't the large mass prevent the gravity gun from picking it up? Which you would expect.

Correct.

Nice to see a fourm that Dr. Matt is enjoying,

use the weight tool addon. problem fixed.

Originally posted by Matthew:

use the weight tool addon. problem fixed.

And on servers where this is not installed or is prohibited?

Originally posted by Matthew:

use the weight tool addon. problem fixed.

The problem with this is that the TARDIS weight influences it's other properties. Try flying the TARDIS when it's weight is set to 1... Good luck...

Originally posted by Dr. Matt:

I can easily modify the weight, but keep in mind weight affects air resistance and stuff

You got a good point there, but that's why this thread exists: To think of ways around that.

All of Dr. Matt's scripts are on GitHub, right? That means they're open source. I'm surprised there aren't more "revised" scripts popping around from different users!

I have another issue to add to the list:

3. This issue has to do with the orientation of the TARDIS when it was called by the Sonic Screwdriver. The problem originally came up around the time of update that allowed the TARDIS to be materialized side-ways or upside-down on a surface. Before that update, calling the TARDIS with the Sonic would materialize it with the front door facing you, which allowed you to accurately position the TARDIS without worrying what direction it would be facing. Currently, this is not the case as the update disabled the Sonic's ability to determine the direction and opted for a set direction that couldn't be designated beforehand without using Navigated Demat or Programmed Demat. I remember asking Dr. Matt about this problem, and he answered that it had to do with how the TARDIS landed on irregular surfaces, which was optimized in that update, but with the backdraw of removing the Sonic direction control ability.

If Dr. Matt could give us some info on that, or correct anything I got wrong, perhaps we can make some suggestions!

You're pretty much spot on JO3Y, Adding the ability to land on walls and ceilings unfortunately forced me to remove the ability to point at the player when landing on a normal floor surface, at least until I get better at my vector and angle maths lol