As far as I know, the only way to upgrade a feature is by calling the Upgrade() method. Any other operation, including deactivation/reactivation, solution upgrade/update etc should in no way force a feature upgrade. I have upgraded some feature after a solution update in the past and they were NOT automatically upgraded by the Update-SpSolution cmdlet (I had to use my edited version of the Feature Upgrade page that Chris developed ^_^). This post on Chris blog also seems to confirm my experience - but anyone, fell free to add further references to Microsoft offical documentation as needed.
To elaborate on your second question - feature upgrade and solution update - they are different concepts.
To keep the same nomenclature used by the page you referenced Solution update is a special case of solution upgrade. You -upgrade- the solution any time you deploy a new version, but only some deploy may qualify for solution update (and even then you may chose to do a full retract/add cycle). As you can see from the linked page when you want to "install a new version of a solution" (the operation MSDN call upgrade - at last most of the times -_-') you have two options:
- Retract solution / Add solution (solution Replacement): the most common option, you retract (/remove) the solution and then procede to add the new version. This procedure often requires additional action to be taken to avoid common problems (features deactivated on the solution retract etc).
- Solution Update: you update the solution without retracting it. In this case, features remain untouched (no deactivation will be performed) but your assembly and other solution files will be updated.
As you see, most time solution update is the easier path to follow, but it isn't always possible due to the limitations that a new version must follow to qualify for solution update. To be clearer, you may want to use solution update to semplify a deploy process when:
- you have only fixed some bugs in you codebehind, so only your solution dll have changed (please - DO NOT think about "I will just drop them in gac" ^_^).
- you have only changed the layout of a custom control (moved a button, changed a label)
- any other case that fits the requirement for update.
Feature upgrade on the other hand is something you may want to use to perform additional action when a new version of a feature is installed in the farm (remember, -you- must trigger the upgrade). Please refer to the documentation for further details - by using the feature upgrade framework you may (only some examples here):
- Add a new field to a deployed site content type and have the change propagated to the derived list content types.
- Rename a file in a module
- Add a receiver handler that will execute your custom code when the feature is upgraded
Those were only some samples of what you can do. Basically with feature upgrade you may define an upgrade path - a set of operation that must be performed to allineate an already active feature to the current version. Just remember that deactivating the feature and then reactivating it will NOT execute any of the upgrade logic.