• the "maxUT" search space needs to be user tweakable
• the "maxTT" initial guess for the max transfer time needs to be user tweakable
• the "maxUT" initial guess for tight circular parking orbit to hyperbolic orbit is likely off -- we're going to always launch nearly immediately, while parking orbits dozens of periods in the future could be better -- but Lunar transfers also have this feature where you're going to get better transfers once a month but in practice we don't care about that (<--- yes actually some people do when the moon is very below the inclination of the launch, although really you want to time your launches better)
• the "maxUT" initial guess for parking orbit to hyperbolic may find the end of the hyperbolic trajectory, should do something about that
• do we just need to display a porkchop plot and let the user select?
• should give the user feedback in yellow text when the optimizer comes up against the boundary conditions to prompt the user to increase them (knowledge is power).
• allow an offset in front of / behind the target in fractions of a period
• allow an offset in front of / behind the target in meters / km
• allow an offset in front of / behind the target in degrees of true anomaly
• allow targeting keplerian elements manually (possibly matching some keplerian elements to target and entering some manually)
• allow matching keplerian elements to "target" to "current" and "free" to be optimized (that latter thing gets fairly stupid hard though since you now need a pontryagin-style end conditions and transversality conditions i think?)
• there may be some additional refinement to make in the initial guess of the maximum transfer time.
• the other callers of DeltaVAndTimeForHohmannTransfer should be converted to DeltaVAndTimeForBiImpulsiveAnnealed
• similarly DeltaVAndTimeForHohmannLambertTransfer should be converted to DeltaVAndTimeForBiImpulsiveAnnealed?
• cleanup the wackiness between the meaning of maxUT/minUT in the different APIs
• drop both maneuver nodes (requires a lot of plumbing changes for maneuvers to return a sequence of nodes -- kind of necessary to make arbitrary keplerian targeting make sense to the end user)

This is going to require better UX -- either we need to have an "advanced mode" button on the existing menu option -- or maybe introduce an "advanced bi-elliptic hohmann transfer" menu option which is the full tweakable planner. Ultimately though it feels like we're going to put a bunch of different menu options out of their jobs at the end of this work so the menu starts to become cluttered with people often just using this option. The UX of selecting target/current/free/pinned/offset for each keplerian element would be awesome, but would overhaul everything about how people currently interact with MJ. That is almost a total overhaul of the maneuver planner. In fact at that point it might just be a tickbox in the options to convert the maneuver planner over to the advanced style.

As far as UX goes there needs to be some kind of convergence between the advanced transfer to another planet porkchop, the advanced hohmann transfer planner, and a future launch to rendezvous UX which should all involve porkchop plot kinds of calculations and need to have tweakable "launch windows". The somewhat clunky mouse-only interaction with the existing porkchop is obviously a problem, and its not even clear that a full porkchop is necessary or desirable (or computable in a feasible amount of time) for some of those cases. But the UX to control the window should be a common design element.