Hello everyone.
The pivot point set to “acive element” works correctly only when the axis is picked with middle mouse button.
If the axis is picked by pressing a lette (x,y,z) or with the transform gizmo, it fails.
So what’s the point of settings the transform orientation and pivot point if in the end it will not work as expected?
I reported this as bug here but they closed it.
https://developer.blender.org/T84259
If this is not a bug it is very unclear and uncosistent behavior.
Thank you.
It has always been inconsistent. There used to be a time when MMB only locked global axes (because doing otherwise required “double-tapping” which you couldn’t do with MMB). Now it locks current transform orientation axes. Inconsistently with X/Y/Z keys 
The handling of pivot point itself is inconsistent between object and edit modes (e.g. translation Individual Origins does behave differently in edit mode compared to other pivots).
That said, I think there is a bug, but not in a sense you see it. It’s not that the MMB is respecting your chosen pivot - it simply applies the currently chosen orientation to overall transformation (i.e. it’ll do the same with other pivots as well), which it seems to take from active object regardless of pivot (with the exception of View for obvious reasons). I’d say that MMB should do what the X/Y/Z keys do (the manual says as much, in so few words), not what it’s doing at the moment.
The behavior you expect for translation with Local/Active would indeed be useful, but it would contradict the behavior of rotation and scale with that same orientation and pivot combination. Ideally, there should probably be a setting for whether to treat translation differently to the other two transforms, though that’d be a missing feature, not bug. Without that, the sad workaround is to use a custom orientation.
There should be no need to use a custom orientation.
In 2.79, desired behavior is possible using gizmo and normal orientation.
The fact that normal orientation is not working as in 2.79 is a regression.
Of course, normal should act like local or local as normal in object mode.
But that is the wrong behavior that has been picked by developers.
What is transformed is the selection. That is not the axis individually defined per objects that should be picked. That should be local axis of pivot point defined for selection.
That is why there is an Individual Origins pivot point.
When user is picking the Active Element pivot point, there is no ambiguity about what behavior is expected.
@MaxPuliero is right. Current behavior is not predictable by user.
@Robert is wrong. There is an issue.
@RonanDucluzeau I’ve left a comment and tagged Bastien. I agree that it is inconsistent behavior, but it is not a bug in the strict sense we use on the bug tracker. I can’t decide how the local transform orientation should work with regards to the transform pivot. That is something the team of the Modeling module has to decide.
thanks Robert 
we probably should have a section of the bug tracker for papercuts.
I think that happened because modeling team wanted to open possibility of multiple orientations & multiple pivot points (like what Individual Origins does but with more options) during 2.8 development.
But they did not really have time to explore such field.
As long as the only thing, exposed by UI, is an Individual Origins pivot : that should be the only way to access transformations involving multiple pivots.
I am not fundamentally against the fact that some transformations could involve multiple custom pivots defined per object or part of selection ; as long as, behavior stays transparent to the user.
One selection + one pointer movement -> result is different things, moving in different directions, relatively to different origins.
That is inevitably something that has a non-intuitive complicated behavior.
Piece of info needed to understand what is happening can’t stay in the shadows.
Anyways, a refactoring of transform pivot point, to support multiple pivots, can’t be a work that can be executed, quickly and instantly absorbed as an intuitive habit by users of community.
I think that the best thing, modeling team has to do, for now, is to clean current situation : to make things work as users will expect them to work, according to current UI.