Unfortunately I still can't dupe the issue. I did, however, fix the VESSEL::CreateVariableDragElement, oapiTriggerPanelRedrawArea, and VESSEL::GetHorizonAirspeedVector warnings in Orbiter.log on startup.

Note that there are still some warnings about VESSEL::GetHorizonAirspeedVector in orbiter.log on the included XR scenarios, but they are not coming from XR code -- I get the same warnings when loading the default Delta-glider/DG-S ready for takeoff scenario, so it must be some other module that is causing the issue (maybe OrbiterSound?).

Anyway, one thing you can try is to play around with uncommenting the following settings lines and setting different values for these two cheatcodes in your Config\XR2RavenstarPrefs.cfg file to see if changes how much your ship "slides around" at KSC or Brighton Beach:

The only way to force a wheel-stop at default-BB-scenario I found so far:
-loaded the scenario...the vessel slightly moves to the right (0.08 - 0.10 m/s)
-started APU...pressed brakes
=able to maintain a stable 0.10 m/s right-move (no more accelerating to > 0.10 m/s
but no wheel stop

-used the RCS-yank commands (numpad 1 and 3) to force a "RCS-brake"
=after some RCS-bursts, the wheels finaly stopped, and I was able to aply the parking-brake

Then I enabled external-cooling, before I quick-saved the scenario

However, after reloading the scenario, the problem is back:
=
-external cooling offline
-vessel moving again to the left...starting with 0.08 m/s

I also tried different Orbiter-difficult settings (like complex-flight-modell etc.), but got allways the same result. (tested in DX7 and DX9 client btw).

I just tried it in a clean Orbiter 2016 RC4 install at KSC with OrbiterSound, UMMu, and the XRs, using both the inline and D3D9 clients, both with and without vertical sync, and it works fine for me -- external cooling is restored and the parking brakes remain engaged when the scenario reloads. The ship does not move.

Maybe it has something to do with framerates? What framerate are you getting?

When using the default "1 - Ready for Takeoff to ISS" scenario, all went fine.
I aplied ext cooling, saved and reloaded the scn.
Ext cooling has been restored an parking brake is still active...no more bounces or moves...at least at KSC.

I also retested it with the default XR2 Landed at Brighton Beach scenario and it works for me -- the ship does not move and external cooling is restored when the scenario reloads with the parking brakes on. Unfortunately, I'm out of ideas here...

As far as I understood, dbeachy1 is testing on RC4 + HiRes texture and turtle91 is testing on latest rev 61 on SVN + LoRes texture.
I'm sure you are aware of how difficult it can be to get a common outcome with such different starting situations (on such a delicate issue, BTW).

I went to Mars...and all went fine.
After landing at Olympus/Pad01, I cannot get the wheels stop using brakes.
It's a bit strange, because the vessel reported a full "wheel stop" and it stays on position, even after going to max time-accel.
Also all MFDS are "quite", so the vessel is def. at a stopped state.

But the wheels are spinning very slowly, so I cannot aply the parking-brake, or connect any external resources.

The only way to stop the wheel-spinning is to use RCS a bit.
As soon as external view shows no more-wheel-movements, I can aply the parking-brake.
But...after a couple of seconds, the parking-brake dissengages, and the wheel are starting to spin again.

Again, while all this happens, the vessel is stable on the ground...no moves..just the wheels.

Set a fixed time step under Extra | Debug on the Launchpad. This should nullify framerate-related differences between runs on different computers, and make tests reproducible.

Open the object info dialog (Ctrl-I) for the focus vessel and scroll down to the bottom. You'll see an indicator ACTIVE/IDLE. As soon as this switches to Idle after landing. the vessel is considered fully parked as far as Orbiter is concerned. This should happen 5 seconds after all criteria are satisified (ground contact, no thrust forces, linear and angular velocities below a fixed threshold

Turn on the force vector display (Ctrl-F9). In addition to the weight/lift/drag forces known from Orbiter2010, this also displays (undocumented) friction forces from all surface contact points. This might or might not provide some insight.

Many thanks martins, this makes the trouble-shooting a bit more structured...no so much guess+tries.

I have tried the suggesting changes/settings, and the outcome seems to be XR-vessel-only-related:

I tried various fixed timestamps, but got allways the same result:

-when the scenario loads-up, it takes about 5 seconds to have the "IDLE(landed)" status in Orbiters point-of view (CTRL+-I)
-but when displaying the vectors, I can see at least one vector which seems to be still active:
Here I have an ultra-fast-changing vel-vector which points from the middle of the ship in the SE(relative to ship-nose) direction and aplies all the time 0.218 - 0.219 Nm.
When I aply the brakes, the value goes down to stable 0.184 Nm.
But reaching "0" for a short time is only possible when using RCS.

So...maybe we some kind of "invisible neverending RCS force", which might lead into the problem ?

...just to add, I tried in DX7 and D3D9 client, all other modules disabled, but got allways the 0.2xx Nm SE. (angular torque force)
I have also emptied all the fuel/RCS recources, but..."the force is still with me"

Edit:

I just found out, that every vessel in orbiter shows an angular torque, even while "IDLE(landed".
So maybe we need just some kind of: "if all vel-vectors are < 1 ....stop the wheels to avoid further logic-issues by still moving wheels...."