In such scenarios you always want to fully merge the release(-like) branches. So make sure nothing is missing.
But during the merge you can freely modify the content -- including to drop or redo some changes. For your example case, merge the branch, revert the commit you don't like, and squash that revert into the merge commit. Obviously make a note in the merge commit message of that action.
If the fix is already on devel, merge will just skip over it, or you resolve the conflict by selecting the devel version.
The point is you want the history show as your second figure, and the state as it makes best sense.