Zhetaan

First off, welcome to the party, Stephen.
Second, have some of the punch, because this one is going to be tough.
I'm going to assume that you're in space and not on the surface of a celestial body:  if you are on the Mun or Minmus or some other place, then you can walk back to your craft; it can take some time but the jetpack is not necessary.
On the other hand, if you're in space, rescuing your Kerbal is less of a maths-intensive issue and more a matter of fine docking control.  Since you've managed to expend an entire jetpack's worth of fuel, I'll also guess that you have not yet learned the finer points of rendezvous and docking ... which means that most likely, the ship you exited for your EVA is not equipped to perform the rescue.
That's okay; it just means that you have a new mission.  Before you go much farther, it would be a good idea to go into the map view and see whether your Kerbal is going to fall into something's atmosphere.  If so, then it may not be possible to effect a rescue in time, and you may need to accept that.
Otherwise, I'm going to assume the worst case that your Kerbal came out of a single-seat command pod and the ship is now uncontrollable, but that both are in a stable orbit.  That's okay, too:  it means that you can do two rescue missions.  In the meantime, it gives you the time to learn how to complete those missions.
First, I'm going to give you a list of places to look for rendezvous and docking help.  You may need to build new ships in order to work on this--and if you need to do so, there's nothing wrong with starting a new sandbox save so that you don't also have to worry about funding your own training.
Scott Manley's 2014 Docking and Rendezvous Video Orb8ter's 2017 (version 1.2) Rendezvous and Docking Tutorial Video Lithobreaking Works's 2018 Rendezvous and Docking Tutorial Video These are all YouTube videos; text-based tutorials (of varying age) are in the Tutorials sub-forum.  I am personally fond of tutorial campaign written by @Pecan called Exploring the System that was made for version 0.90, so it goes back quite a ways.  While I don't think the ascent vehicles in that campaign will work anymore, the docking trainers are a good design if you want to learn how to do it--and you will want to learn how to do it.
Once you understand the ideas behind rendezvous, docking, and fine manoeuvring in orbital space (this may take some time), you're ready for the more difficult part:  you need to learn how to dock with something that has no ability to control its own motion.
There are two ways to accomplish this.  The less desirable by far is to use a Klaw:  it will absolutely grab a Kerbal.  However, it will not put the Kerbal back inside the spacecraft, which means that rescue needs to include provisions to protect that Kerbal from re-entry.
The second is to try an unpowered docking procedure, with the caveat that rather than bringing a docking port to the Kerbal, you bring a ladder instead.  This requires extremely careful and slow motion, a rescue ship that is preferably perfectly balanced, and you will need to switch to the Kerbal while on final approach in order to use the Grab command when the ladder comes within reach of it.
It also requires a specially-designed rescue ship that either includes a probe core or two seats (make certain that one of them is empty!), RCS and monopropellant, and ideally as compact a design as possible so that you don't waste time trying to turn the long dimension about.
Aside from the fact that you won't have docking ports, rescuing the Kerbal is about as straightforward as regular rendezvous, aside from the aforementioned requirement to switch to the Kerbal while you approach so that you can use the Grab command.  After that, if you like, you can move to the abandoned spacecraft and rescue it, too.
 
I know I'm short on details, but I really can't provide more than a general procedure until and unless I can find out more about your specific circumstances.
Good luck!

@EndTraveler:
All of the K+ torch drives use water and karborundum at a 50 : 1 ratio.  If I'm not completely off, that's by volume, not mass, so it's a matter of having 50 units of water in a water tank for every unit of karborundum in a K+ tank as seen on the resource tab; you don't have to figure the densities or anything like that.

@Vojta:
First, welcome to the forum.  I'm sorry to hear about your rocket trouble, but from what you've shown so far, I have a few ideas.
Nine seconds is very specific, so it points to a problem with the design rather than with the piloting.  I would expect both engine exhaust damage and staging issues to destroy the rocket more quickly, but it is worth checking both of those.
However, I suspect that your main issue is a combination of too-flexible connections in your core stack and too much thrust.  If your rocket flexes a lot before you release the launch clamps, that may be a clue.  In that case, the boosters burn off fuel which decreases their mass, increases their thrust-to-weight ratio, and increases the severity of any oscillations to the point of rapid unplanned disassembly.  Since the burn rate is constant, the destruction is predictable; hence it always happens at nine seconds.
As to the thrust, I noticed that you reached a maximum gee force of 6.0 gees.  That may be because of the way the rocket was destroyed (blasting the root part away at high speed will often trick the accelerometer) but it also says that you reached a speed of 213 m/s and at least an altitude of 1,120 metres.
If you could do that in nine seconds, then I think you have too much rocket.  Extremely high thrust will also stress the connections between parts and try to break your rocket apart.  If the connection is even a little flexible, then the tip of the rocket (which, if well-designed, has most of the mass) will deviate from the thrust direction.  Add the distance to the engine and you get a lot of torque on the joint; add extreme thrust and you multiply that torque to the point of breakage.  Torque, for the lay physicist, is force times lever arm times the sine of the angle between them; in KSP, this is roughly related to thrust times rocket length times the sine of deflection.  Given that the last item in your crash report is a linkage failure between a fairing and the base ring, I suspect very much that this is your issue--torque-related destruction is about the only way to get a base-fairing linkage failure in Procedural Fairings.
I don't know how TweakScale deals with connection strength, but it's possible that when you take a small part and make it into a large part, it will not scale the strength enough, or it scales the mass or thrust too much, or what-have-you.  If nothing else works, try a scaled-down version of your rocket and see what that does.

To do that, you would have to change the definition of gravity in the game and make it a finite-ranged force.  If you do that, then it isn't gravity any more, and in any case, leaving such a hypothetical SOI is identical to leaving the universe (and in a departure from modern cosmology, the KSP universe nods to Galileo and Copernicus by making the Sun the centre of it).  If I'm not completely mistaken, you can leave the KSP universe every time you quit the program[citation needed].  Of course, your spacecraft can't, but if you were to somehow rewrite KSP to let you take a craft with you and run it all over your desktop, then although it's an interesting idea, it wouldn't tell you anything about the behaviour of the stock program what with the program no longer being stock.
It's not really a proper question to ask how something will respond when you do something that exceeds its constraints, except perhaps to characterise the type of overflow error that would result.  That's somewhat like asking what happens to the characters after the end of a book--the question has no meaning in the context of the story because everything that happens to the characters happens in the pages of the story, and if more was supposed to happen, then it would have been written.  This happens in a way with sequels, but that's no longer quite the same story.

@Streetwind, @PrvDancer85, @Starman4308, @Spricigo:
Here's the update.  I kept getting weird numbers when I tried to fit the curve.  My initial guess values tended to be off a bit--which I expected from trying to use a quadratic fit on a cubic spline--but when I tried to fit a cubic, I started to see values that didn't make any sense, especially for Eve.  Either KSP or Unity is doing something odd with the spline, and since I don't need to bother figuring out the equation when I want obtainable data points, I decided to get empirical data instead.  That means that I strapped every engine in the game onto a sandbox monstrosity, turned on all the cheats, and went to every planet with an atmosphere.  Duna has no sea-level terrain; I believe the lowest elevation is about 170 metres but I don't know exactly where it is, so I decided to use a spot at about 270 metres.  Cutoff pressure is taken from the configuration files.
Normal LFO engines:
Engine Vacuum Duna Laythe Kerbin Eve Cutoff Pressure (atm) Ant 315.0 299.4 160.0 80.0 0 3.0 Spider 290.0 288.1 272.5 260.0 114.1 8.0 Twitch 290.0 287.4 266.1 250.0 83.8 7.0 Spark 320.0 316.4 289.5 270.0 88.9 7.0 Reliant 310.0 307.1 278.9 265.0 88.2 7.0 Swivel 320.0 315.7 268.9 250.0 48.4 6.0 Terrier 345.0 327.7 173.4 85.0 0 3.0 Vector 315.0 313.7 303.5 295.0 193.3 12.0 Dart 340.0 335.3 303.6 290.0 230.0 20.0 Thud 305.0 303.1 286.6 275.0 139.7 9.0 Mainsail 310.0 308.4 295.8 285.0 147.8 9.0 Skipper 320.0 317.4 297.2 280.0 57.4 3.0 Poodle 350.0 332.7 160.2 90.0 0 6.0 Twin-Boar 300.0 298.7 289.1 288.0 147.6 9.0 Rhino 340.0 331.1 252.9 205.0 0 5.0 Mammoth 315.0 313.7 303.3 295.0 193.3 12.0  
Solid Rocket Boosters:
Engine Vacuum Duna Laythe Kerbin Eve Cutoff Pressure (atm) Flea 165.0 163.4 150.2 140.0 28.3 6.0 Hammer 195.0 193.4 180.2 170.0 57.4 7.0 Thumper 210.0 207.7 188.9 175.0 35.0 6.0 Kickback 220.0 218.4 205.4 195.0 66.7 7.0  
Jet Engines:
Jets operate differently from other engines.  Their Isp is always the Kerbin sea level value; the thrust varies with the velocity of the engine and a curve called atmCurve which is distinct from atmosphereCurve.  Of course, there needs to be enough oxygen entering the engine to keep it from starving for the lack, but technically, the Isp on Eve or in space is the same as on Kerbin.
 
Utility, Odd, and Other Engines:
Engine Vacuum Duna Laythe Kerbin Eve Cutoff Pressure (atm) Nerv 800.0 759.3 375.7 185.0 0 2.0 Rapier 305.0 303.1 283.3 275.0 139.7 9.0 Puff 250.0 241.4 165.5 120.0 0 4.0 Dawn 4200.0 3927.2 1480.9 100.0 0 1.2 Sepratron 154.0 151.6 131.5 118.0 22.6 6.0 Launch Escape System 180.0 178.7 168.2 160.0 69.7 8.0  
There were a few interesting discoveries here.  One thing to note is that, in terms of performance, the Vector really is one engine from a Mammoth cluster; everything is exactly the same.  Another is that the Spider is much, much more capable than the Ant in terms of atmospheric operation.  This by no means is an assertion that the Spider is a valuable launching engine, but it does mean that you could probably make some fun glider drones with it, and these things would work on Eve, too--the Spider can operate at some truly high pressures.  The Hammer cuts off at a higher pressure than the Thumper; if you are silly enough to take SRBs to Eve, then take Hammers over Thumpers because Thumpers at Eve sea level are operating too close to their limit, and the Isp values reflect this.  The Dart is the only engine that operates at 15 atm; if you're even crazier than the one who took SRBs to Eve, then the Dart is the only thing that works at Jool's datum (zero altitude point).  I don't know whether any rocket can climb out of that far down Jool's gravity well (pressure may be a problem before you get that low anyway), but the Dart is the only thing that can try.

@ej89:
The cake is a lie.  So is the 'unlimited contract' feature of Mission Control.  @nightingale's Contract Configurator will let you have up to 18, I think (and it offers some other features that you may like, so have a look), but I believe what you'd really like is found in Gamedata\Squad\Contracts.  It's a file called Contracts.cfg, and near the top is a line that says 'AverageAvailableContracts = 10'.  Change this to what you like.  Just be mindful that there is a limit for a reason, so watch out for issues that may arise from raising the limit to something absurdly high.

@DrPastah:
No, there's no preference for which side of the link gets the stronger dish:  the range in root mode depends only on the antenna combination, not the order.  However, the solution is easy:  add stronger dishes at Kerbin.  You won't even need to re-do your current satellite constellation:  just have one new satellite in a large-radius polar orbit (this reduces the chance of occultation) that has a dish powerful enough for Duna and enough antennas to connect to your existing constellation.
As to the reason why you cannot connect, the range is not the average or arithmetic mean of the component antennas' ranges; it's the geometric mean.  The formula for it is √(r1r2), where the r values are the antenna ranges involved.  90 Mm x 90 Gm gives 8.1 x 1018, and the square root of that is 2.846 Gm.  There is also something called a clamping value, which says that an antenna is limited to a hard increase of 100x its base range for omnis and 1000x its base range for dishes, but we're not running up against that.  The idea there is that it keeps you from using a DP-10 to communicate from Eeloo just by linking it to a stupidly-overpowered dish at Kerbin.  This also means that you will never be able to connect a KR-7 (which, if I have it right, is what you're using at Kerbin) to anything more than 90 Gm away, because 90 Gm is 1000x the KR-7's range.  When linked to a sufficiently-powerful dish, they can reach Duna, but the dish you chose to use at Duna is not powerful enough.  You'd need something rated to 4.5 Tm or better to connect when Duna is 20 Gm away.
The issue is essentially that while Duna has powerful dishes orbiting it, the ones at Kerbin are so weak that they can't transmit a usable signal with enough strength for the Duna dishes to sort from the background noise.  In reality, more powerful antennas are perfectly capable of picking out the signal from weaker antennas.  For example, sensitive antenna technology is what allows us to continue communicating with the Voyager probes (at least, I'm fairly sure that no one's upgraded Voyagers' radios), but the simplified model used in RemoteTech does not allow for that because it doesn't simulate noise at all.  They're working on it for RemoteTech 2.0, but there's nothing like a release date on that yet.

There is a button in the Space Center View (and in other views, but this is the first place you can access it when you begin a new game) called KSPedia (it looks like a little white book with a blue rocket on the cover) and it has some more information.  It is possible that the wiki stopped carrying much tutorial information once a lot of that information became available in-game.
Don't worry too much about spending all of your money before you found Mission Control.  Most contracts pay a little in advance (mainly to pay for the rocket that you will use to complete the contract), and simply getting a rocket into the air gives a lot of what are called 'milestone' bonuses, which pay rewards for doing certain things for the first time (first launch, first EVA, first orbit, first time leaving the atmosphere, first time going certain speeds or distances or altitudes, and so on).  Or, if you'd prefer, you can start a new game.
You need to upgrade the Tracking Station to level 2 to make manoeuvre nodes.  You need to upgrade the Astronaut Complex to level 2 to go EVA anywhere but on Kerbin's surface.  You need to upgrade the Research and Development Complex to level 2 to take surface samples (and I think you need to upgrade the Astronaut Complex as well).
The Research and Development upgrade is extremely expensive, so you probably won't do it for a long time, but you should consider upgrading Mission Control to increase the number of contracts you can take.  If you can get, for example, four contracts to test experimental parts at the Launch Pad or on Kerbin's surface, you can combine the tests into one rocket that never leaves the pad.  That gets you a bit of money with no real expense (it's not a lot of money but if you need it, this is an easy way to get it) and it's a lot more convenient to do several contracts when the limit is seven contracts (from a level 2 Mission Control) rather than two (from level 1).
Aeroplanes are supposed to be somewhat more difficult to fly than rockets; if you're having trouble making a stable rocket then I suggest you take a second look at your rocket design.  The rocket parts you get to start are not the best but you should be able to get them to fly straight, at least.
Also, welcome to the forum.  If you need any information about anything KSP or rocketry in general, please don't hesitate to ask.

It also helps to set the other rocket as the target (you can do this in map mode) because that will give you a set of markers which show you the point of closest approach.  They look a lot like the Ap and Pe markers, but they are different colours and they have a vertical line down the centre rather than lettering.  The orange set shows the next point of closest approach (the one pointing down is your position, and the one pointing up is the target's position), and the magenta set shows the point of closest approach on the orbit after that.
What you will want to do is modify your orbit (generally, you want to lower your orbit if the target is ahead of you and raise it if it is behind you, but if you're orbiting at low altitude, you will have to go higher either way to avoid grazing the atmosphere and re-entering) and then wait until the separation gets close.  For these sorts of approaches, it sometimes makes sense to circularise at the modified orbit because it makes the rendezvous go more quickly, but for small changes, it usually works better to keep one apsis at your target's orbit and stay elliptical.  As the markers get closer, that is a visual indication of how much your target is catching up to you (or vice versa).
Eventually, the target-position marker (the one pointing up) will skip over the closest-approach marker.  This indicates that your target will pass you on the next orbit.  That's how you know that it is time to change your orbit back towards the target orbit.  However, you don't want to change it the whole way:  you want to get to the same place as the closest-approach marker and slowly thrust to move the orbit back while watching in map mode.  What you will see is that the target-position marker will slide along its orbit:  what you will want is to slide it to align with your closest-approach marker.  When that happens, shut down your engines.  Your orbits aren't yet matched, but you won't want to fully match until you have actually rendezvoused.  You can check the separation distance on the closest-approach marker; it ought to be under 2.5 km and ideally under 1 km.  Closer is better to a point; I usually try for 0.2 km because I don't want to have any collisions and because 200 metres is quite close enough for orbital rendezvous.  Collisions aren't likely but I had a nasty surprise once when I tried to rendezvous with a station, so I stay safe.
Now you have to wait one more orbit, and once you get to the point of closest approach, you ought to see the target floating next to your rocket.  Now is the time to fully match.  The way to do this is to set the navball to target mode (do this by clicking on the speed display at the top of it) and thrust retrograde until the target velocity equals zero.  Retrograde when you're in target mode is defined with respect to the target's relative velocity; so making it zero means that you and your target have matched orbits.  The match isn't perfect (and it won't be unless you dock) so the target velocity will start to rise as you drift apart, but a good rendezvous will give you a fairly stable match for at least five minutes, which is plenty of time to do most anything.
If you are more visually-inclined, Scott Manley does a better job of explaining it than I do, because he has pictures:
And the second part:
 

Try this:
https://imgur.com/gallery/qBiem
 

@angelgiga:
Tanks of a specific type can only hold that type of resource.  The rationale is that the storage and insulation requirements for liquid fuel and monopropellant are different from one another, so you should no more be able to just throw liquid fuel into a monopropellant container and expect it to work than you can throw diesel fuel into a gasoline-powered car.  Practically speaking, tanks are configured with specific resources and changing the resource requires changing the configuration.
Interstellar Fuel Switch does allow switching in flight if the tanks are empty, but you have to have the tech for it.  I'm honestly not certain what the requirements are.
You may wish to look at Configurable Containers, which also allows switching tank types in flight but also allows you to customise the final setup.
 
... And since this is your first post, welcome to the cozy little family.

The first answer that comes to mind is that the delta-V you see is an idealised amount that assumes your burn is instantaneous.  Reality spreads that burn over time and causes you to use more delta-V.  This effect will be magnified by longer burn time, which in turn relates to available thrust from the engines.  Therefore, the ion engines, being the weakest, suffer the most from it ... but that's a lot of loss.  If you'll tell me the orbital parameters, I can run it through the equation and let you know whether your delta-V readout is bugged.

@rocketBob:
There is an equation, but it is not a pretty one.
Also, inclination is not a problem provided that the orbital period is resonant with the Mun's rotational period.  For example, a circular, Kerbin-synchronous, one-day, polar orbit will still pass over the same longitude once every orbit (that is, once per day).  An equatorial version of the same orbit holds position over that longitude indefinitely.  Intermediate inclinations and eccentricities show greater and greater apparent motion with respect to a surface observer, but so long as the semi-major axis of the orbit remains the same, it also remains synchronous (and the motion will appear periodic ... because it is).
The equation for orbital period is this:
T = 2 * pi * (a3 / GM)1/2
where:
T = period
a = semi-major axis
GM = gravitational parameter, which for the Mun is 6.5138398×1010 m3/s2
In your case, the easy solution is to have your T equal to 138984 / n seconds, where n is some integer and 138984 is the Mun's rotational period in seconds.
However, you don't want the period; you want the apoapsis, which means we need to rearrange the equation:
a = (GM * T2 / 4 * pi2)1/3
To simplify this for the Mun, we can pre-calculate a number of the parameters and combine constants:
a = (6.5138398×1010 * T2 / 4 * pi2)1/3
= (1.649974896×109 * (138984 / n)2)1/3
= (3.18718×1019 / n2)1/3
For n = 1 (a synchronous orbit), the value of a is 3.170556×106 m, which, less the 200,000 m of the Mun's radius, gives a circular orbit at an altitude of 2.9706×106 m.  This cannot be used because the Mun's sphere of influence ends at 2.4296×106 m.
For n = 64, the value of a is 198159.8 m, which puts the orbit under the Mun's surface.  The reason this is undesirable is left as an exercise for Jeb's piloting.
For n = 58, the semi-major axis is 211600.6 m, and that means a circular orbit at 11,600.6 m because such a low orbit is only barely enough to clear the Mun's mountaintops. 
It also means that you will have to wait 58 orbits to get a resonance.  Keep in mind that for all of these values of n, the number of orbits is largely irrelevant; excepting cases of crash or escape, the orbits will add up to one overhead pass of your chosen landing site for every Mun rotation.  The spacecraft will pass over the correct longitude many times--58, to use the maximum safe value--but those passes will also but for one be at the wrong latitude unless the landing site is on the equator.  If the orbit could precess, then it would be possible to achieve your goal a little more often (at the cost of some truly frightening calculations), but precession requires n-body gravity.
To take these values with a fixed Pe and obtain a useful Ap requires one more bit of mathematical wizardry.  The semi-major axis is to an ellipse something like a radius is to a circle, but because it is an ellipse, you can have varying Pe and Ap values that still give the same semi-major axis.  For the Mun, the semi-major axis is:
a = (Ap + Pe + 400000) / 2
where the 400,000 is the Mun's surface diameter and the Ap and Pe are taken as altitudes from the surface (as KSP displays them).  If we hold the periapsis at 15,000 m then the equation simplifies to:
a = (Ap + 415000) / 2
and combining this with the earlier equation gives:
(Ap + 415000) / 2 = (3.18718×1019 / n2)1/3
and once rearranged, this gives:
Ap =  2 * (3.18718×1019 / n2)1/3 - 415000
This constrains n by quite a bit:  for example, you can no longer go above n = 56 because that lowers the 'apoapsis' to below the periapsis.  You can also no longer go below n = 4 because smaller values of n require either your Ap to be outside the Mun's sphere of influence or your Pe to be above 15 km.
I will assume that your mission profile is such that you will prefer either a long, languorous time at a high Ap or a close-in, near-circular orbit.  For this reason, my suggestions to you are to use either n = 4 or n = 56.
For n = 4 and a Pe of 15000 m, the Ap is 2.101473×106 m.  The orbital period is 34,746 seconds.
For n = 56 and a Pe of 15000 m,  the Ap is 18218 m ... approximately.  The important thing is to make certain that the orbital period is 2481.9 seconds.

@nascarlaser1:
@dafidge9898 has the right idea.  However, when the periapsis goes below zero metres, it doesn't turn negative; it just disappears from map view (Kerbal Engineer and some informational mods will display a negative Pe, but map view will not).  The orbit line will still be drawn, which is what can be confusing:  the orbit lines in KSP don't detect collisions with the surface.
My usual method for getting to the Mun is to set up the burn and then click on the Mun in map mode; there should be options there to set as target and to focus view.  'Focus View' is what you want.  Then start the burn.  When it enters the Mun's sphere of influence, you'll see the line of the encounter, and as you continue burning you should see it get closer and closer to the Mun's surface.  You should also be able to shut off the engines before you too much of an encounter, if you catch my meaning.
For burns further away and where absolute precision isn't so important, I tend to do it in two parts:  I burn once to get the encounter, and then I set up a second burn to fine-tune my path to the final trajectory I want.  The Mun is so hard to miss, though (I suppose you know all about that now), that it isn't worth the trouble or the fuel to do it in two steps.
Edited to Add:  When you do get your encounter, don't let the Pe go below 10 km.  That is a good, round number that also avoids all of the highest points on the Mun's surface.

3 is the best, mass-wise.  1 requires you to pack transfer stages for five landers, which means you have to pack additional dV into the mothership to move the transfer stages.  2 is better, but if you're moving the mothership around anyway, why not just go all the way and use the mothership to move within the system?
Another possibility is to use an interplanetary tug to get everything to Jool, but then your 'mothership' is, in turn, an intraplanetary tug.  That way, you can, in essence, spiral in to the system (or out) carrying only the mass of what you need to visit the moons (are you discarding landers as you go?) and avoiding the essentially parasitic mass of your return vehicle.  Then you can return to the return vehicle and return to Kerbin.  Be sure to incorporate elements of 4, too--you want to encourage the moons to mess with your orbit, if the end result puts you where you want to be.  Free dV is the best dV.
Another option is a bit like 4: you come in with a low Pe to Jool, and as you capture, you toss away landers when your Ap is at the right orbit.  You can set this up as a multi-burn manoeuvre, going round Jool before burning for a lower Ap (and also to let the alignment favour a lander's transfer window), and it saves you the dV of having to raise and lower your landers' orbits to go wherever they need to go.  Then you only need them to pack the fuel to come back.

I know that in pre-1.0, it was uncommon-but-not-surprising to see jet-based first stages.  However, the cost of jet engines compared to LFO rockets--let alone SRBs--made it fairly expensive in career.  I don't know whether it's possible in post-1.0 to do it; jets took a blow to performance.  Additionally, the jets were oriented vertically, and you are asking about launching from an aeroplane.
I've seen a few YouTube videos of people who launched their rockets from jet-based launchers.  The challenge comes from KSP's internal mechanics:  if you pilot the rocket, your jet may crash before you circularise, but if you pilot the jet, instead, you may not be able to land it before your rocket coasts to reentry.  And if you pilot either one, the game may delete the other if it drifts too far away in atmosphere!  Assuming that the wiki Recovering Spent Stages is still correct, you'll need to get a lot higher than 20,000 metres.
Here's an example of a powered recovery (rockets, though, not planes--but it gives you an idea of the challenge): @Raptor9 made a great video of flying a Recoverable Booster.
Also, per the usual refrain, there's a mod for that:  feel free to try @SIT89's FMRS.  It was last updated officially for 1.1.0, but the thread says it works in 1.1.2.
As far as viability, the endpoint of this line of design thinking is that you get a vehicle whose only recurring cost is the fuel it uses.  We already have that endpoint: you're applying the same principle that guides the development of an SSTO.  You aren't quite to single-stage, of course:  this is still in 'recoverable booster' or 'First-Stage-to-' territory.  Even stretching the definition and calling your booster an FST-not-quite-O or maybe an FST-almost-O still means you have parasitic engine mass in the rocket payload when compared to a full SSTO (which, for this comparison, has no rocket payload).
On the other hand, the expenditure of engine mass is academic if the engine is recovered.  The only true cost with a 100% recoverable spacecraft--and concordantly, the only viable standard for viability when considering such craft--is fuel expenditure.  Because that rocket payload's engine is parasitic mass, you're using more fuel in the booster to lift it, even if it is only liquid fuel and not LFO.  Will an aerolauncher use less fuel than a staged rocket?  Absolutely--even if you ignore lower stage destruction and don't include (parasitic) recovery engines or parachutes.  Will it use less than a rocket SSTO?  Maybe--I'm not sure how the cost interplay between extra engines versus extra oxidiser works out.  Will it use less than a jet SSTO?  Absolutely not.

Yes, they changed the buoyancy calculations; submersibles are a thing now, too.  Of note is that ore sinks; using different tank sizes in combination allows for a crude but effective stock ballast control.