Here's some sneak peek of the new version, using lots of FFT, UI designed for touch access and a tiny LCD screen.
(targetting 480x244 px at 4", resistive touchscreen)

About Simple screen - the icons are placeholders and that display will be draggable. The list will contain typical reverb types.
About Eq screen: the dotted fields will contain a nice draggable-touchable curve (incl. scrollbars most likely, I'm thinking on how to implement zoom) and the list will have some operations to apply to the graph, like smoothing, sharpening, reducing to only negative dBFS, reset, copy and so on.
The checkboxes are tristates - you can enable, disable or use an automatically derived eq. (either an average or a copy of the other side)

The app will have true distance computation, but I'm wondering if I should expose the silly things like temperature and humidity, which do affect the sound at higher distances.

All of this will be written in Python - w/ Cython, Numpy, Scipy, perhaps Matplotlib, PyMusic (for Portaudio) and perhaps some ctypes VST wrapper like PyVST or my own in Cython.
Not Faust anymore, as it's more suckage than it's worth and nobody knows it anyway.
I haven't decided on the reverb engine, we'll see after I have some performance figures. Might be block-based convolution reverb even where you can provide your own IR samples. Full HRIR upload is not excluded either.

ITD will also be FFT-based with frequency-dependent fractional delay, filter designed using least squares for each band separately. (minmax gives wiggles and is way harder to write)
Thinking 256-point FFT is enough, block-based to reduce delay to 32 samples even.
Probably 32-bit float computation only, due to ARM NEON/Intel SSE limitations - I'll probably have to write a bunch of ops in C or assembly anyway to speed up numpy and scipy.

Yes, though VST is not the primary target as of first release, I'll add the support.
(JACK is the primary target, you can make that work in Windows system-wide too. There's also ASIO to JACK bridge, so it can be used in any ASIO-supporting application, such as VSTHost.)

The tricky part will be making it not look like on Windows, since it's GTK+ 3.
I'm not sure if the center channel should be separately equalizable and am considering replacing that with a balance control instead. What do you think?

I'll also need nice reverb stereo impulse responses. Right now I can use the "Hamburg home" freely available ones, but I'm not sure about bundling them - will add some free TAP Reverb generated ones at the very least.

The trickiest part right now is implementing Mel-weighted least squares for the EQ and ITD, drawing that and dragging the curve along. I also have to add a biquad-alike to make it simpler to use given limited input on the target mobile device and if using keyboard. (I have 4 to 7 physical buttons but also a touchscreen - except touchscreen is terrible for fine adjustments.) The actual derived eq will be drawn as well, as it does not have to necessarily exactly match what you have drawn for various mathematical reasons.

The progress is slow, since I had a hard crunch at work. (Related field too, so I do not exactly like to work on it after hours.) It will get done though, there's nonzero progress.

I'm currently trying to implement a good enough algorithm for (approximate) linear phase equalization.
It will either be plain FFT (or probably even sliding DFT) graphic equalizer with time delay equalization, synthesized least squares FFT/sliding DFT or non-uniform FFT with optimized band choices.
If you know how to make NUDFT sliding in O(N) sense, I'd love to hear about it.

First I tried IIR optimization for given time domain and frequency domain results, but this turned to be impossible - two of the algorithms produced unstable or acausal results in specific conditions.

The other problem was that there is no way to make the UI work with a small screen and a required large number of bands for direct input even with a touchscreen, so I want to do it with cosine-shaped parametric bands.
(Cosine is better for NUFFT, but theoretically anything can be used for least-squares, including biquads.)
This also needs some work for real time plotting, I've almost figured that part out.

By distance I meant:
- air frequency absorption (essentially an equalizer)
- crossfeed and ITD (larger distance = different feeding)
- stereo width (lower)

Maybe:
- early and diffuse reflections in case of synthetic reverberation, but the plan was to use captured IRs instead

Gain loss is unnecessary to tune I think and hard to do so, unless you have SPL-calibrated headphones.
That's why there's a separate gain knob.
The distance assumes that default position is binaural - this has to be tuned by the user, as weirdly equalized headphones can mess this up.

The advanced screens have additional tunables, e.g. separate humidity (controlling HF absorption), temperature (controlling speed of sound), ability to load any complex or real HRIR (4-channel), directly tweakable interaural time delay curves.

I will also need to figure out a way to make those more advanced settings usable for a layman, perhaps via some kind of wizard for equalization and ITD tuning.

By minimum phase you mean constant minimum phase FFT, yes? Otherwise, IIR phase discontinuities interfere with ITD, causing cancellation artifacts and phase reversal in bass, breaking some kinds of electronic music.
I could do minimum phase FFT, but I'm not sure it is any better - perhaps optimized preringing FFT, so 66% postringing FFT.
Do remember that headphones are minimum phase themselves, so it's better to not have to much additional postringing.
The effect is nearly inaudible anyway.

Direct equalization is part of advanced options, you know. It is 4-channel. I'm considering breaking up the app into multiple windows at this point. The simple ones will be for the selector/wizards and simple spatial and reverb controls.

The real way of tuning EQ for users would be a list of headphones, assuming good quality control and measurement conditions, the results should be good. Only minor additional tuning should be necessary.

Wizard-like tuning also works - I've seen Samsung do something like this with AdaptSound - you get a series of sine tones that should be equal loudness - the problem with that specific implementation is low resolution, but if we know the headphone in question, it is easy to pick the critical bands requiring tuning for a fast tuneup.

Obviously, 3k-8k region is the most important for spatial positioning. And instead of sine tones, which are very annoying in this range, I can use medium-Q bandlimited noise.
Peak width and position searching could be also done with slow exponential sweeps, asking the user to click a button when the tone gets louder or quieter than comparison tone - of course it takes a relatively long time, but then the results are much better. First run rough EQ, then refine the peaks.

I might consider also doing SPL "calibration" by using binaural samples and channel imbalance correction. (Stereo equalization is excellent for imaging and simple most of the time.)

  Any updates on this Astral?