Unix/Posix time doesn’t include leap seconds (it’s 86400 seconds per day, always, per definition [0]), whereas UTC, taken as a count of actual seconds, does include leap seconds. So you are right that converting between them requires additional data. However, few applications care about converting between Unix time and that notion of UTC, but instead care about converting between Unix time and calendar dates and times of day and time zones, which is easier with Unix time than with a UTC seconds count. So I think you’re mixing things up here.
It would be more accurate to say that Unix time "accounts for" leap seconds by not accounting for them at all, but rather switching into temporal displacement ambiguous repeat timestamp la la land for an entire second before returning to an unambiguous encoding of UTC.
Leap seconds are not counted in Unix time. Otherwise days with leap seconds would be counted as having 86401 seconds instead of 86400 seconds. This is not the case. In the example you cite, the Unix time resets to 915148800 after the leap second (1999-01-01T00:00:00), so the leap second isn't counted. Unix time differs from the true number of seconds since the epoch by the number of leap seconds (plus the UTC-TAI time difference between 1970 and 1972, before leap seconds were introduced).
Most likely. They could add leap minutes, hours, or days instead. But they'll probably set UTC as a constant offset from TAI, and let the few uses that care about accurate solar time use UT1.
If you want something tied to Earth's rotation, UT1 is the way to go. If you don't care, TAI is good. UTC is in a weird compromise position, where it (traditionally) tried to be within 1s of UT1 but otherwise tick at the same rate as TAI. That compromise turned out not to be what anyone needs, so future uses will probably pick between UT1 and TAI/GPS/Unix/some other fixed offset from TAI.
[0] https://en.wikipedia.org/wiki/Unix_time#Definition