Basically the issue is that different vessels needs different ascent path, so I have to remember to change them every time I use different ship. Would it be possible to create some sorts of system that would allow me to save several presets and switch between them. Preset had to save apoapsis and ascent path form.

We do plan to implement something of this sort.

This would be perfect for custom windows as well. I propose three different memory spaces for all persistence-enhanced functions.

1. Root
   I see this as the overall default. Brand new ship? These settings get applied until otherwise stated.

2. Craft
   This would be specific to the unique craft file. Sending up multiple probes? Designate these settings, and every identical ship afterwards will share them.

3. Ship
   So you have multiple space tugs, but one is pushing a probe, and the other is the root of a space station. Or you have two identical probes, but one has already arrived at it's destination and no longer needs as much info. I see this as where your UI and other persisting edits normally get stored, using two other buttons to commit changes to higher persistence levels.

Typical workflow

Finishing a brand new design, you send your ship to the pad. Generic settings load, opening the default info pane. Deciding you want another value displayed normally, you add it in and save the change to tier 1. All future launches that have no other persistence information will now include this value. Then you add in phase angles and other interplanetary information/operations because this is an interplanetary probe. You save the settings to tier two. From this point forward every time you launch this craft file without modifying it, these changes appear. After flying to destination and achieving desired orbit, you no longer need most windows. Removing them does not change their appearance on other ships, but you can travel away from this craft and return, and they will not have reappeared.

Closing this as an old MechJeb issue. Many MechJeb issues have had little interest in years, have been fixed for years, do not include adequate replication steps, refer to old problems which are no longer applicable, or are difficult to determine what the problem is. This issue is being closed for one of those reasons. We apologize for any inconvenience, but keeping the TODO list tidy helps the developers.

If this bug/issue is still a problem, please open a new issue. For bugs please try to include a Minimal, Complete, Verifiable Example that explains all the steps required to replicate the issue. A link to the KSP.log file should be ideally included, but is often not sufficient information. Screenshots or short videos are often the best way to show a bug.