Leap seconds are normally ignored since they are way too short and to few in relation to the quality of normal clocks. And not placed according to mathematical formulas but actual measurements.

Your PC don't have any leap seconds. The unix epoch time don't have any leap seconds. The only thing is that in some situations, programs should be prepared to survive seeing a seconds value of 60 and not just 0..59.

Leap seconds can be important to know about when converting from raw GPS time into UTC time, since the GPS time reference is not using leap seconds and so drifts away from UTC time. Note that the GPS may hide this by adding an offset before presenting any time.

Leap seconds can also be important do be able to detect, when picking time info from a time reference somewhere, where the received time can have 60 as seconds value. But the next value will still be zero, so a program receiving 60 in the seconds field can pretend it saw 59.

The important thing here is that the leap seconds are decided about based on measurements. They aren't inserted from a mathematical rule. So you can't write an algorithm that takes care of them, without also making use of a lookup table that gets regularly updated based on decisions made about when next to insert a leap second.

So no - I don't agree about that "must be implemented as feature and not an option".

When a time protocol (or an user) sets the time 2012-09-07 11:16:20 to an embedded device, that embedded device don't need to know how many leap seconds there have been since 1972, unless the embedded device is used for very, very specific tasks. And in that case, the internal time values internally will not be any unix epoch of seconds since 1970-01-01 anyway.

If an embedded device picks up the time from a GPS, it is important to check if the GPS sends out the raw GPS time, or if the GPS was designed to make a 20+ second correction. But still - that don't give you anywhere to add in any algorithmic processing of leap seconds. An embedded device don't know if there have been more leap seconds unless the user changes that offset or unless the embedded device have network access to a server somewhere to look up a list of past and comming leap seconds.

The ultimate embedded device for handling time is a normal clock. Our clocks obviously don't have any need to know about leap seconds unless they are set from a radio-based time reference. And then they still don't need to know about the number of leap seconds - just that they can convert the second value 60 to 59 because the next seconds value will still be 0.