You wouldn't want to run it completely open loop; of course, that will kill you on ambient alone, nevermind manufacturing differences. But if it's a temperature controlled outer loop, the only effect a variation in resistance has is changing the loop dynamics (how fast/slow it can respond, and over what range of voltage/current) and what the maximum temperature difference is (which will be limited by supply voltage, current, DCR of the device, and whatever max delta-T it supports).
You'll still want short protection or something like that, just because it's a switching app, and leaving the inductor completely alone to itself is dumb. You'll also need some startup for the output filter, and yes you can simply soft-start the whole thing, but if it gets interrupted and freezes or jumps suddenly, you still end up with the same problem.
One example: set up two transistors as a monostable timer. Turns on until inductor current reaches threshold, then ticks off. Restart it with a pulse. You can have the pulse simply be a constant frequency (short duty cycle, or filtered so it's edge sensitive), and vary the peak current -- so you're making a half-MCU, half-discrete UC3842 basically. To control power, you need a DAC output (to adjust the peak current threshold), and/or the adjustment of frequency. Peak current mode, of course, works best in DCM (discontinuous conduction mode), which means a fair bit of ripple (relatively large capacitors and inductor).
You can run PWM from the MCU, but gate it through a missing pulse detector (so if the output accidentally latches high somehow, the output fails safe). And put a peak current detector on there to shut it down for the rest of the cycle (thus integrating the flip-flop action of the previous case), or for some time (in which case it acts like a self-resetting fault). Follow up with a gate driver and transistor.
You could do worse than an average-current-mode controller, but this is much more involved. You need an independent PWM generator, and run an op-amp to control output current. But running the current setpoint signal from a DAC leaves the least attention to the MCU -- it only needs to update the setpoint when an event occurs (presumably, the temperature PID will be on the order of one or a few samples per second).
Conversely, the most software-intensive version might use the internal analog comparator (tends to be slow, but at a low enough frequency, this isn't terrifically bad) or software polling (and external comparator) to control PWM per cycle. Or the cycle is just a software counter, who needs timer-counters. I wouldn't suggest average current mode control, because you need an ADC that can sample at least once per cycle (something an ATtiny or ATmega won't do -- at least, not with rated accuracy; though if only a fraction of the bits are important, it could be quite doable).
Tim