Key problems

1. Package A is updated from 1.0 to 2.0, breaking package B which depends on A 1.0.
   • breakage is not always detected
     • Example: ceres depends on an exact version of eigen (a simple bottle refresh could fix it)
   • breakage can't always be fixed
     • B may not support A 2.0 until its next release a month from now
2. Package B,C depend on different versions of package A. Package D depends on both B, C and sometimes A directly. (other variations on this theme exist)
3. Options sometimes break invisibly
4. Cross tap dependencies may change

Solutions with most backing

These are reasonably easy, well liked ideas that will mitigate (but may not completely solve) the above

• allow a limited set of versions into homebrew supported taps with an aliasing mechanism for the latest version so dependent libraries can have a soft landing until they support new versions
• define criteria for accepting requests/proposals to make certain options recommended by default

proposed solutions

This is the full list of proposals (not definite upcoming features). Check marks indicate they are implemented

• checking all formulae for broken dylib linkage
• rearranged brew audit output format
• allowing versions for widely used directly into homebrew supported taps where appropriate
  • this seems particularly popular and supported by several commenters
• "maximal options" test
• dependencies on specific versions in formulas
• allowing version phase-ins / phase-outs
• side by side install of versions (where possible)
• keg only installs of versions
• alias the latest version i.e. boost is boost160
• allow multiple acceptable dependency versions to be specified perhaps with a preferred option
• easy way to remap dependencies like brew install mypackage --override-dep boost ahundt/boost155. could be a normal brew command or perhaps an easy way to change the formula files?
• move libraries and system services (not end-user applications or GUIs) that have dependencies in the Homebrew org to being versioned on the next major upgrade
• allow multiple versions to be specified in a single formula
• define criteria where proposals to make certain options recommended by default is encouraged

posed problems without solutions

these are from the ongoing conversation beyond the initial request posed above

• version dependency conflicts for multiple packages. Here is an example:

A: depends on boost (latest)
B: depends on boost155 (newest feasible version)
C: depends on A, B, sometimes various boost versions

• cross tap dependencies may change

Original Feature Request

I keep having libraries I depend on get broken because those dependencies' own dependencies are changed out from under them. In particular, this happens most frequently when flags other than the default are needed.

Two examples:
https://github.com/Homebrew/homebrew-science/issues/3454
https://github.com/Homebrew/homebrew-science/pull/3512

Perhaps there is a way to avoid these problems that also meets the crucial criteria of the homebrew team being willing to put it into practice? :-)

Thanks for your thoughts and considering my request!