For various reasons light poles tend to be made to be easily bent/broken (in fact, it's also safety related).

So I'd argue that to avoid competing objectives/priorities one should not combine bollards and light poles, otherwise one goal or the other will get compromised, quite possibly in opposite way than they should for given location.

Essentially, making them separate is a physical infrastructure form of making incorrect states non-representable.

The big problem in the US is that the same reasoning that is used to design roads where speed is expected (cars are going fast, a static pole means the car ends up wrapped around like a pretzel around the static pole, make the pole break away so the driver can survive) is applied to cities where speed isn't expected and there are people not protected by a metal cage walking around.

Streets and roads must be designed differently, but I see stroads in the US that are multilane roads with the only nod to safety towards anyone outside a car being low posted speed limits, incongruent with the design safe speed of the road itself.

There are various reasons even in cities to make most utility poles easily breakable.

OTOH a bollard has an explicit different purpose that makes it easy to design for it.

> Essentially, making them separate is a physical infrastructure form of making incorrect states non-representable.

Huh, that's a great example, because it also shows why making light poles double as bollards is an alluring idea. A scenario I see somewhat often is when you need to change some existing code working on a piece of state, because now that piece of state actually has two mutually exclusive substates. Say, Auth = {username, password} becomes Auth = {username, password or path to certificate }.

The easy solution would be to add the new properties and perhaps mark them and their conflicting counterparts optional - this means you have to refactor only the type definition and maaaybe some points of use of the now-conflicting substate. In our example, Auth = {username, password?, certificate? = nullopt}.

The proper solution would be to "make incorrect states non-representable", representing the substates directly -- Auth = {username, {password | certificate }. Or perhaps, Auth = {PasswordAuth | CertificateAuth}, PasswordAuth = {username, password}, CertificateAuth = {username, path to certificate}. Now this is a much more substantial change, and you'll end up touching and possibly changing every place Auth is used.

Under resource constraints (such as time), the easy option is very, very tempting :).