As far as I remember the SPICE algorithms you do not want its internal matrices dumped on you. Also I believe for transient analysis it converts all capacitors to voltage sources (and inductors to current sources) for every time step and solves the non-linear circuit like a DC one. So there are no true differential equations in SPICE.
That said, SPICE could output the transfer function of the circuit; IIRC as a list of polynomial coefficients. This sometimes suffers heavily from rounding errors but for simple circuits it may be what you are looking for.
It has to do with what can be easily evaluated at elaboration time, formally, what is called a "locally static expression". This is an obscure looking rule, but it deserves some thought - eventually it does make some sense, and your simulator is quite correct in alerting you by generating non-obvious results.
Now, temp(1) can be evaluated at compile time (even earlier than elaboration time) and it can generate a driver on bit 1 of "temp".
However, temp(i) involves a bit more work for the tools. Given the trivial nature of the loop bounds here ( 1 to 4 ) it is obvious to us humans that temp(0) cannot be driven and what you are doing is safe. But imagine the bounds were functions lower(foo) to upper(bar) in a package declared somewhere else... now the most you can say with certainty is that temp is driven - so the "locally static" expression is temp.
And that means that the process is constrained by these rules to drive all of temp, at which point you have multiple drivers on temp(0) - the process driving (no initial value, i.e. 'u') and the external temp(0) <= '0';.
So naturally the two drivers resolve to 'U'.
The alternative would be a "hacky little rule" (opinion) that if the loop bounds were constants, do one thing, but if they were declared as something else, do something else, and so on ... the more such oddball little rules there are, the more complex the language becomes... in my opinion, not a better solution.
Best Answer
The problem is that you are expecting a model to have more functionality than it has. Most models are simply parameters in an equation. They are designed to approximate the actual device behavior within specific operating conditions. For example, a diode is modeled using the following equation:
\$\Large I_f = I_S(e^{\frac{Vf}{NV_t}} - 1)\$
Where Vf is the applied voltage and If is the forward current. Notice that there's nothing stopping me from putting 50V as the applied forward voltage, and I will definitely get an answer from the simulator. It will be completely nonsense, but the model is assuming that the behavior of the diode is always described by that equation.
I have seen device models with voltage breakdowns and melting currents, but typically those are in "high end" models used for IC design. It is specifically coded into the models. I'm using Spectre and HSPICE, but I don't think that's going to help you much. If you MUST use a simulator to identify if a part is going to fail, then you need to understand when the part is going to fail and watch the simulation results for those conditions.
Relying on a simulator to guarantee whether or not a part works is asking for disaster. Simulators model everything as "ideal" - and that is making a LOT of assumptions. Keep in mind that a simulator considers everything perfect unless told otherwise. Doing conceptual design with a simulator is dangerous.