As I explain in the linked post, there is no technical difference. As the two events are usually defined, in both cases after the fork there are two versions of the rules, "permissive" and "restrictive"; and what happens next depends only on which version has the majority of the hashpower (which of course may change after the fork, and in principle could even go back and forth several times).
Of course there is a technical difference. The definition of the difference is purely technical.
The only difference is whether the rules before the fork were "permissive" or "restrictive"; but that difference has no effect on what happens after the fork. Only the relative amount of hashpower is relevant.
And there is a major difference in what you are calling "safe". In the case of a soft fork, the miner risks mainly itself by not adopting the majority rule. In the case of a hard fork, the whole consensus on the valid chain can be at risk and there can be long chain reorgs. This doesn't happen in soft forks and this is a MAJOR difference.
But (as explained in that linked post) which of these two possibilities happens does not depend on whether the fork was soft or hard, but only on whether the majority of the hashpower
after the fork follows the "restrictive" or "permissive" ruleset.
If the majority uses the "restrictive" ruleset, there is one "restrictive" chain with recurrent "permissive" side branches that get orphaned sooner or later. This can happen even in a hard fork with blockchain voting, if the miners lied in their votes, or changed their minds afterwards.
If the majority uses the "permissive" ruleset, there are two persistent branches; the minority "restrictive" one grows more slowly at first, but it is still followed by any "restrictive" full clients. This can happen in a soft fork with blockchain voting too, if the miners lied in their votes, or changed their minds afterwards.
If 100% of the miners use the same ruleset, of course there will be only one branch. By making changes be conditional on blockchain voting, with a large activation threshold, it is
hoped that there will be such a large imbalance after the fork that the minority miners will prompty switch too, preferably before the fork.
However, in any case, clients who are running the minority version after the fork will be screwed or confused in various ways. If the split is not 0-100, even some clients who are runnng the majority version may be temporarily confused by the minority branches.
A rule change is really safe only if
all miners and
all clients upgrade to the same version before the change is activated.