In general we try to keep the CiviCRM developer interface with CiviCRM as stable as possible. Ideally hooks, payment processor extensions and api calls should change as little as possible between releases.
In every release there are some improvements and additions. Generally the place to find out about these is the api change log - ie,
Unintentional changes can also happen. Our first line defence against these is the unit test suite. Basically if something is tested then with very few exceptions it should continue to work. So, if you want your code to be stable - get to know our tests!
Very very occassionally we make intentional changes to api behaviour. In 4.6 I have changed the behaviour of relationship api so that it will no longer fail if you try to update the contacts on an existing relationship. This error doesn't seem to have any real logic and causes pain. See https://issues.civicrm.org/jira/browse/CRM-15786
A more notable change affects payment processors - if you write payment processors you should take a look at https://issues.civicrm.org/jira/browse/CRM-15555 and https://issues.civicrm.org/jira/browse/CRM-15714
In a nutshell in 4.6 it is possible to override form interactions with payment processors in the payment processor class - including declaring the fields to display, the validation to do, and even to override the whole payment form buildForm.
There is however, one change that 'could' be unexpected. The $form object used to be a property of the payment processor class. In 4.6 the payment processor is a property of the form - so this circular logic had to be removed. I cannot think of any situation where accessing the form object from the payment processor would be useful - but perhaps you could & did? if so please add your input here or on the ticket.