It depends on what you're doing and on what you need.
If I had a bunch of scalar objects, and I'd added some to the end of a subtree to support newer equipment, and the older equipment didn't support it, you'd just rely on the older equipment rejecting requests for the newer OIDs. That's perfectly cromulent.
If your MIBs are more structural, with tables, you can either:
- Do the same thing; just add more fields to the table that are conditionally supported, or
- Create a second table with the new information, sharing an index with the first one to effectively "extend" the first table. However, this may be overkill, and your users will have to poll both tables independently; semantically, however, they will be neatly linked.
In general you want to try to avoid extending your MIBs. Think of the data you'll need up-front to the extent possible, regardless of the state of hardware support. Of course in reality you will think of/invent features later so it cannot be entirely avoided. Certainly don't change OIDs: that's prohibited.
By the way, though the lexical notation of a MIB is ASN.1, the scheme you're really using is SMIv2.