What if any proposed blockchain enhancements that require hard forks would require new ASIC hardware? From what little I know about ASIC they are not flexible with regard to the tasks that they can execute. Some of the proposals for scaling bitcoin up require hard forks in the blockchain. I read about one proposal about replacing the ECSDA signing algo with Schnorr that made me think of this question.

I'm wondering if any of these hard forks would actually mean that some or all current ASIC miners are rendered incompatible and worthless? This would of course have an impact upon which solutions are likely to go forward. 

I expect it depends on the design on the chip, if only the core hashing power is offloaded to the ASIC but everything else is done on a more general CPU. Are most of them designed like this?
I don't think many hardforks would make ASICs obsolete. Developers would surely want to avoid that, and will always have a way to avoid it. Unless they have a reason to make all ASICs obsolete on purpose (extreme mis-behaviour by miners could theoretically cause that). In that case they could chose a different mining algorithm.

The ASIC simply gets fed the prepared header of a block and all it does is run hashes on it while increasing the nonce (32 bits) and possibly a few other bits (in the timestamp field) in case the nonce is too small. So only those bits that it actually touches could possibly cause the block to become invalid. It's highly unlikely that the developers would ever change the meaning of those bits in such a way that it would become more restrictive and cause the found blocks to become invalid under the new rules.

Hypothetically I guess one example could be where the developers decide to restrict the allowed error margin of timestamps in headers. Currently a block is allowed to have a smaller (older) timestamp than the previous block (up to two hours if I'm not mistaken). Suppose the developers decide that from now on it can only vary by 20 minutes. If the ASIC is happily incrementing the enough of the last bits of the timestamp field it could make it exceed that margin, making the block invalid under the new rules.

I guess ASIC manufacturers need to be a little bit careful, or make the ASICs flexible enough so that they can be told which bits to touch. Although I guess the above example might be a reason for the developers to never improve the timestamp accuracy (at least not in the straightforward way).