OHara

The problem seems to be that there is no way in the game to remove the binding of the key for "Docking Mode"
You can work around by editing "settings.cfg" finding 'UIMODE_DOCKING' and changing  the entry to "primary = None"

When this came up before, OhioBob remembered (correctly, as we later confirmed) that zero-celestial-longitude points directly away from the center of the galaxy in the skybox
Now we have a nicer-looking skybox, without such an obvious center to the home galaxy, but I attached screen shots of the bit of sky that serves the role of 'first point of Aries', and of the easier-to-find galaxy in the opposite direction. 
he Alt-12 debug menu Flight Info also gives current latitude of the craft, for those of us who don't use Kerbnet.
Maybe we should suggest that Squad not display the LAN in the orbital-information tab, because it is never useful for normal gameplay.

The density in the alt-F12 aero-data display changes ±1.5% with time of day, in a way consistent with temperature, so I presume it changes as temperature changes with location.

You'll notice after a save/reload that only the end of the strut placed first remains. 
As I remember, the 50-kg mass is added to the part to which the strut is first attached, and remains on that part.
I tried to measure drag of struts and found it to be negligibly small or zero.
So if you placed the struts by starting them on the parts to be dropped, their second ends should have no effect on the later stages.
I haven't tested this in a long while, so let your curiosity triumph over laziness when you get the chance.

You can find the old textures in the VAB/SPH by slecting the 'Enable advanced mode' ||> button in the upper-left corner of the screen, then one of the categories other than the usual 'function' f(x).   For example 'Filter by Module' then 'Engines' 

The Engine-Plate collider is a disk-shaped mesh enclosing the plate, no collider for the shroud meant to go around the engines.  You can use Collide-o-Scope to see them in-game.
But, parts of the same craft are not supposed to collide with each other at all.
I have seen a remotely similar problem with the SM-25 service module (bug report).  Parts connected to parts that are connected to the SM-25 can, under unusual circumstances, erroneously 'collide' with the SM-25, often being ejected violently.

Two possibilities spring to mind.
1) if you touch nose-wheel first, that pitches you up, and then the wings catch more air and bounce you up.  Real aircraft do this and it can be very embarrassing.  You have to slow down enough that you are pitched up enough that the main wheels touch before the nose wheel, but probably you knew that.
2) if you touch main-wheels first, and then the airplane pitches down, and then the nose-gear compresses fully, there is a bug (20682, some workarounds mentioned at the link) where the strut kicks back unrealistically hard.

There is a User-Interface bug that fits this description exactly.  https://bugs.kerbalspaceprogram.com/issues/20753
If that is your problem, save your craft, exit the VAB and enter again, and then always click on the Δv button rather than hover over it.

So far, the best advice is to try again, maybe squaring up the alignment like Cannon did in the thread below.
There is some bug here, but whenever I try to make an example that always fails, it starts working.

ShadowZone gives six steps to solve the problem, many involving Valve's system 'Steam'.
If you don't use Steam, the same symptoms might appear on the first start after adding/removing a mod or mods,
and are solved by closing and restarting KSP.

I get the same result, so not likely anything wrong with your install.    
The new look of the flea booster seems to have come with some (accidental?) performance improvement.   
It sounds like you already know how to deal with this: reduce the thrust, or let the higher-performing flea lift more mass, etc.
Edit: maybe not a bug.. 
The difference is in the drag, which is calculated from the shape (no overrides for these particular parts) and the new shape is just a bit more aerodynamic. 
That tiny difference in shape happens to get magnified by games they played with drag back in version 1.2 (exaggerating the differences in drag-force from different drag coefficients Cd) and the solid boosters do their work in the thickest part of the atmosphere, so a small shape change made big a difference in height

Just to be sure you know, pressing Function-3 after a collision shows you what KSP considers to have collided into what.  I think you will see "M-P-Lab collided into Mk3 Cargo Ramp" but often pressing F3 clears up mysteries.
The science lab has a lot of drag relative to its mass.  With KSPs simplified aerodynamics, when that lab is decoupled laying loose in the cargo bay, as soon as the bay doors are open even a crack, it feels the full force of the wind as if it was outside the aircraft, and that gets it moving pretty quickly.   Once it starts sliding down the ramp, its velocity relative to the aircraft reaches 6-10m/s pretty quickly, and apparently skidding along the ramp above the 'impact tolerance' velocity causes destruction just as badly as hitting it squarely.
I had a moderate success rate https://imgur.com/a/KnW2Hf0 (craft file).  Slowing the aircraft below 80m/s and opening the bay wide worked; so did decoupling the lab then slowly opening the cargo bay.  
(KSP versions 1.4 -- 1.5.1 do have a bug where crossing the joint from an Mk3 bay to an Mk3 ramp faster than the 'impact tolerance' velocity can destroy parts, even though there is no wall on the connecting ends of these bays.  But, when I tried the cargo plane in 1.5.1 that didn't cause any trouble; avoiding damage from sliding along the bay walls forced me to go slow enough.)
It is easier to drop fragile things out the belly of an aircraft, with Mk3 bay with doors opening downward, because the parts are clear of the aircraft before they have had time to build up much relative speed.

As you may well know, the goals of immediate return and low-delta-v are in conflict.  The usual low-delta-V Hohmann transfer has you en-route when Kerbin and Duna are closest to each other, ('conjunction') with Kerbin passing on the inside.  Then you wait until half a journey-time before the next conjunction to return, and the conjunctions are a couple years apart.
You could find a low-delta-V solution that has a long transit time, sitting in orbit around the sun until the next alignment rather than waiting on Duna, but that would seem to miss the point. 
You could look into leaving a couple months early so that you arrive at Duna during Kerbin-Duna conjunction, and the leave essentially immediately.   The transfer-planners are not set up for exactly this, but you can use them to find the least-expensive trip with a fixed arrival date (the conjunction).  It would cost more delta-V but maybe not too much more.

There is a workaround available in version 1.4.4.
Make the EVA Kerbal board the seat, then F5 quicksave, F9 quickload, then any enclosing cargo-bays or fairings shield the Kerbal from drag.

That is an unfortunate effect of a combination of features of KSP (each of which is nice on its own) when SAS is active on a complex craft.
When you use the IVA view for a pod, the control-from-here point is changed to that pod (so the control inputs are aligned to that pod).
The SAS tries to slow the rotation of control-from-here pod.
The control torques are applied at the reaction wheels.
Joints between parts flex.
Large craft have wobbling resonances, where the control-from-here pod might be yawing right while the part of the craft housing the reaction wheel is rotating left.
So by trying to slow a rotation to the right by commanding a turn left, the SAS is making the reaction wheel (already turning left) turn left even faster, and thus pumping up the wobble.
You can solve the wobble by removing any link in that causal chain.   I like turning SAS off.

Before the bug, and presumably in 1.4 when it comes, switching craft and back to the asteroid-mover left 'previously undisturbed' condition satisfied.  I always though the 'previously' meant before accepting the contract. 

Dihedral in the wings is the classic solution.  
First, though, if you have a large vertical stabilizer on the tail, you should try to reduce its size. and make sure it is above the center of mass so it gives a little bit of correction to roll.
When the plane slipping to the side, there are forces that make it yaw into the relative wind, and those that make it roll away from the relative wind.  If the yawing forces are relatively larger, you spiral. With the center-of-lift and center-of-lift indicators turned on the in SPH, you can select the root part and shift-A to yaw it 5°, and see how the moved center-of-lift is trying to turn the craft. 
 

There is also the induced drag from the lift (the kinetic energy left in the down-wash of your wake, per unit length of wake) which is a separate entry 'L-I-D' in the aero-gui, just below your screenshot.  At low speeds, the lift-induced drag is relatively higher.  I think 'L-I-D' plus individual parts' drag adds to the displayed total.

These started to appear in 1.2.9, which introduced languages other than English, so I would assume it is a bad interaction between the system for generating the contract text and the system for selecting among the translations of that text in each language.
Similar cases have been reported, so there might be a fix coming soon in 1.3.1.  
 

When I try the craft you linked in KSP version 1.2.2 it is very nearly neutral in roll, returning to wings level with about a 100-second time-constant.  In version 1.1.3 a few short months ago this stability seemed impossible.  The code cleanup leading to version 1.2.0 seemed to help many such details in KSP.
Even when I auto-strut to heaviest, it rolls only 0.5°/s (roughly).  Auto-strut asymmetry was also much worse in version 1.1.3.
Auto-struts are still relatively new, and were added to solve different problems, such as keeping rovers in still cargo bays.  Given the way you approached this aircraft, I think you will get more out of KSP if you leave auto-strutting turned off.
The aero-GUI rate readouts behave as if they were rotation rates, in °/s, with the axes of rotation being aircraft-Relative and Absolute (I'm just guessing words that match the 'A' and 'R' labels and which match the behavior).   Next to heading for example, you see yaw rate relative to the aircraft yaw axis, and then heading-change-rate relative to Kerbin.  Pull your airplane into a 90° bank and pull the stick back hard, and you'll see what I mean.

Try toggling the brakes on and off.  If that doesn't work, try (re)setting control-from-here to whatever commands the rover.  (And tell us which worked for you.)
 

The best solution was to use the latest driver from the manufacturer of the graphics chip.
With an AMD Radeon R7 M360 on Windows 10:
Windows'  update-driver utility installs driver version 15.201.1101.0,  6 August 2015, which shows the problems in the top post;
AMD's website offers driver version 16.150.2401.0, 15 April 2016, which resolved all those problems.