Refuse deselection of the Active thing.

Not a fan of this. I am not familiar with the selection code, but I am assuming selection is stored in a list. If the active object is deselected, the last object in the selection list should become active.

When box selecting (or any multi select) I think we could set the last object returned by the selection process to be active. This is somewhat random, but I think it doesn't matter as long as it's consistent.
If I need a specific object to be active, I need to select it afterwards anyway.

In general it's a good idea to discuss this. I agree it doesn't make sense to have something active but not selected

Yes I agree, deselecting the active thing should make an other selected thing active, ideally the last one in the order of selection... Is selection order a thing in blender?

I recall a similar discussion during the 2.80 alpha where the behavior was changed a couple times. Back then it was about hiding objects and if hidden objects should be allowed to be selected/active.
The resolution was that hidden objects cannot be selected but can be active since there are benefits to keeping the data of an active object in the properties editor visible even while it is not selected/visible at that moment.
There is also the solution of pinning the data block in the properties editor but that workflow is slower. Some tabs can also not properly be pinned since they contain multiple data blocks (object data tab includes the key data block)
IMO if the pinning would get some improvements I could see it working that deselected objects cannot be active.

Another thing I can think of is that it would be important that when hiding and unhiding things it would remember which one used to be active and then make it active again.
It should never feel random which thing is going to be the active one.

Add this weird/confusing case: Active but not selected

In T82359#1047062, @Christoph Lendenfeld (ChrisLend) wrote:

Refuse deselection of the Active thing.

Not a fan of this.

Me neither, but it's an approach and I just wanted to have it mentioned.

I am not familiar with the selection code, but I am assuming selection is stored in a list. If the active object is deselected, the last object in the selection list should become active.

Selection state is stored on the things themselves, and not as a separate list of selected-thing-references. This also means that there is no sensible order to the selection state; there is no "last object in the list".

When box selecting (or any multi select) I think we could set the last object returned by the selection process to be active. This is somewhat random, but I think it doesn't matter as long as it's consistent.

Well, consistent and random are quite the opposite. I don't think that "the last bone that was loaded when that library override system processed it" or "the object that happened to be put last in memory while parallel-loading five different blend files" are reasonable things to pick.

If I need a specific object to be active, I need to select it afterwards anyway.

True, but that shouldn't get in the way of us making it reliable & predictable. For example, a closest-to-mouse approach could influence in which direction you box-select.

In T82359#1047099, @Luciano Muñoz Sessarego (looch) wrote:

Is selection order a thing in blender?

It is not. I also don't think we should depend on this. For example, say you have bones A-F selected, and then you box-select bones E-H. What's the selection order? If bone A was the active one, how does selection order tell you which should be the next active bone?

In T82359#1047270, @Julien Kaspar (JulienKaspar) wrote:

I recall a similar discussion during the 2.80 alpha where the behavior was changed a couple times. Back then it was about hiding objects and if hidden objects should be allowed to be selected/active.
The resolution was that hidden objects cannot be selected but can be active since there are benefits to keeping the data of an active object in the properties editor visible even while it is not selected/visible at that moment.

Thanks for the historical view, this makes sense and should be considered here as well. I do agree that things can get very nasty when you modify something you cannot see, which is what the "hidden objects may not be selected" thing was about.

In T82359#1047293, @Julien Kaspar (JulienKaspar) wrote:

Another thing I can think of is that it would be important that when hiding and unhiding things it would remember which one used to be active and then make it active again.

This is what happens with the active keyframe right now. When it's not selected, the function to get the active keyframe will feighn ignorance and say "nooo, nothing is active, reeeealy", and when the "active" keyframe is selected again, that same function will just return it as the active one.

It should never feel random which thing is going to be the active one.

Yes, very much so.

As this is such an important topic, I'll hold off on a full discussion that goes into possible solutions until bug-fix week is over.

Notes relating to changing the active object behavior:

• Making active only available when selected makes more sense for geometry (as is currently done with mesh vertices and f-curves).
  
  Unlike objects where the UI for the active vertex is fairly minimal, objects on the other hand have their own modes which intern have their own selection states.

• For objects years back I tried linking active to selection, this causes the UI to flicker since toggling selection for example, makes the property editor *flicker* in a way that wasn't so nice.

• The active object also defines the mode the user is in, so if (using the outliner or python API) and object becomes de-selected, this would exit the mode.
  
  Of course we can try prevent that happening ... or only apply the active+selected rule when in object mode, just flagging this as an issue since it's likely to complicate the design.

• Some discussion on this topic: D4217: Select new active element using box/circle/lasso select [WIP]

• Picking an active item for the user could cause all sorts of problems, as an item could be technically visible, yet hidden for all intents and purposes.
  
  This is especially true for the 3D view, although it could happen in other views too (something could be obscured by the redo panel, or a gizmo... or in the corner of the screen where users might not look). In the 3D view this becomes even more involved (consider all the clipping options, geometry with low alpha, non-mesh objects for e.g. lamp guide-lines which could be in-view yet not an obvious candidate to become active).

Is there an agreement that the current situation causes issues, and that having a stronger correlation between Active and Selected is a good thing?

While the current situation can cause issues, any solution to this is likely to cause issues too (picking the active item for the user has many side-effects).

Currently the active+selected situation is a bit odd/quirky, yet, its a simple mental modal: The active is effectively "last picked", as a user this didn't bother me.

You know what you last picked, you can toggle the selection, add to it with box select, lasso etc, and you never need to think - did Blender change what I "last picked".

Not to say it's the best design, just that it's predictable.

My main concern is the solution is likely to have a more complicated mental model, users will try to understand/second-guess how Blender is tracking the active - or be dissatisfied with the behavior when it's not working how they would expect it to.

A design that handles this well might need to make much bigger changes to how Blender uses the active object.

Animators at the studio are having problems related to this issue, I'm trying to create a cycle modifier on multiple bones at the same time, the problem is if i try to select all the channels by pressing A here

I think the long term solution here is to remove the concept of "active" for the most part, and have multi-object properties editing (T54862) everywhere instead.

The current situation has issues, but I'm not sure the proposed changes here are really better, since it's unpredictable in other ways.

how would you handle creating constrains? how would you handle parenting? how would you handle copying modifiers or other options from one object to other ones?

I think if we come up with a solution which is predictable enough I think we can nail it, then making editing every selected object's property by default instead of using alt still shouldn't be a big deal (I'm all up for that, it makes much more sense to affect all the selected objects than just the active one and alternatively we could shift the "alt" behaviour so you can still affect only the active one)

What if when doing box/circle/lasso select we assign the active to the closest to the cursor at the end of the selection?

No screenshots of other software please.
https://lists.blender.org/pipermail/bf-committers/2020-July/050616.html

For defining relations between objects and a few other things, the concept of active is fine. It does not have to removed entirely. But it would be irrelevant most of the time with multi-object properties editing.

sorry, my bad!.

Yes it can be irrelevant in other things but having it allows for great workflows like "rotate to the pivot of the active object" which we cant lose, its part of blender's beauty.

Note that Python code that relied on bpy.ops and setting an active object, may not have bothered to also set that active object as selected, so depending on the resolution here such addons may need to be updated.

I feel like due to the reasons Campbell outlined, it might be better to, instead of preventing the two problematic cases, we would improve support for them. For example, I think it wouldn't be the worst thing in the world if, after de-selecting a thing, it would still be indicated that it is the active one. It may certainly be confusing for new users, but that's already how Blender behaves anyways, it's just not indicated at all. This would also probably be the easiest solution, even though it re-defines the problem a bit. So themes would need three colors, "selected", "active", "selected+active".

Even after 10 years of using blender actively, deselecting and having something stay active still confuses me, sorry that's very personal.

with all due respect: I think that's adding more complexity to a matter that should be simple, selection should be simple and you shouldn't need to think much about it, otherwise it becomes a slow process which you don't want in the most performed action, and really adds no use case.

Shouldnt be too complex:

1. you click object: its selected and made active.
2. you click outside, object is deselected and the object stops being active.
3. you select a group with box/lasso/circle, the closest to the mouse cursor at the end of the selection gets to be the active object.
4. you shift click a non active object that is within the selection: It should be deselected. ( because most of the times you dont want to make one more object the active, you just want to deselect one object from the selection )
5. you shift click a new object into the selection it should be added and become active.

@Luciano Muñoz Sessarego (looch)
I strongly agree. The list you outlines should be the case for all "things" and not just objects.
Especially with the behavior of T54862 this should work really well and make selecting and setting things as active way more convenient (Although users will have to get used to point 3 of the list).

The biggest hurdle for me and probably others would be to get used to deselection causing the properties editor to switch to scene related tabs.
Maybe there's a clever solution to avoid that instead of having to use the pinning icon more often?

@Demeter Dzadik (Mets)

it's just not indicated at all.

For objects at least it's indicated. Just in a subtle way. If an object is active but deselected it will have a bright orange origin point in the viewport and a white highlight on its icon in the outliner.
If it would be more obvious (like with an outline) then users might actually think its still selected.

@Luciano Muñoz Sessarego (looch)
I strongly agree. The list you outlines should be the case for all "things" and not just objects.
Especially with the behavior of T54862 this should work really well and make selecting and setting things as active way more convenient (Although users will have to get used to point 3 of the list).

Yes I agree, this one seems to be the more "predictable" one for the user out of the options I've tested.
In <<other competitor softwares>> it feels kind of random for me when you do such type of selection, but it hasn't bothered me at all.

The biggest hurdle for me and probably others would be to get used to deselection causing the properties editor to switch to scene related tabs.

To me really "unselected but active" when nothing is selected is not such a big deal, what breaks me is unselected but active when you have other things selected

Maybe there's a clever solution to avoid that instead of having to use the pinning icon more often?

So maybe the ruling should be "unselected but active" is okay, but unselected but active when there is an other selected object is Not okay.
When there is a selected object the active object should always lie within the selected ones never within the unselected.

So maybe

For objects at least it's indicated. Just in a subtle way. If an object is active but deselected it will have a bright orange origin point in the viewport and a white highlight on its icon in the outliner.
If it would be more obvious (like with an outline) then users might actually think its still selected.

• which is the case on armatures. Interestingly enough sometimes you can have an active object that isnt selected that looks selected...or 0 selected objects none of them showing any signs of selection but still having one active.

For me point 2 of the proposal is a must, but I find having no active element sometimes really useful, at least this is the case for me while modeling. Let me explain:
I use almost all the time "Active Element" as "Snap Pivot Point" and "Snap With - Active" as Snapping method, and I perform box select for having no active element within the selection so the fall-back of snapping behaves as "Median Point" or "Center". That way I don't have to change the snapping configuration back and forth. I would indeed appreciate that deselecting the active element would have the side effect of getting a selection without active element, something expectable, to take advantage of that. I would have another problem with Merge, with now I have setted as merge At Last and, if it fails because there isn't an active element, perform merge At Center, so that I don't have to choose the method every time for such a common operation.
I'm sure this would impact my modeling workflow big time if changed as discussed so far. I don't know someone else's. I don't know if I'm the only one who sees that having an active element all the time would be annoying because it would add additional steps between selecting and operating without automatic workarounds possible like the ones I've just mentioned.

Perhaps it would be a good idea to also take a look at how hiding works in combination with what is active and selected. For instance this caused some confusion in T82359 in the context of hidden bones in pose mode.

To me really "unselected but active" when nothing is selected is not such a big deal, what breaks me is unselected but active when you have other things selected

But that makes sense when using active element as pivot.
If you want to scale things selected and get them closer to active object that you don't want to transform ; that corresponds to a frequent case where selected means transformed and active means point of reference of transformation.
There are cases where you want your reference to be transformed like the rest of selection.
And there will always be cases where you don't want that.

For that reason, it is very useful to support unselected active object with a selection.

Maybe, that is just the word Active that is not reflecting reality of use. It could be renamed Reference object. That would be a more valid denomination.

Surely, the lack of color to indicate an Unselected but Active element is problematic.
That does not happen in Object mode when Origins are indicating active status and absence of Outline is indicating Unselected status.
Real resolution is to find similar tricks in other modes : a way to to show unselected but active status.
But that is not the status the culprit of confusion. It is the lack of visual feedback to communicate it.

What is sure is that removing of the idea of a quick determination of an element of reference for transformations and snapping would impact negatively modeling workflow.
It would be a big mistake.

Proposal 2 is a must, this is definitely expected behaviour. What interesting with mentioned downsides of this: in case of extending of exisiting selection you will already inevitable have active element, so it will not changed. So there is no problem with choosing active element. The problem arise only when selection is created "en masse" - like A key in EDIT/OBJECT mode or L key in EDIT mode. And deselection of active item in current selection turns into same "selection initialization" problem basically

Choice based on closest to mouse position would not be great decision though, imho... mouse position is generally random, this will feel mostly broken.

Two possibilities/suggestions here:

1. Make active element closest to 3D cursor (vert in EDIT, object in OBJECT, etc) among selected. 3D cursor generally always floating around of "Point of interest" during modelling sessions, so this will give reasonable choice in many cases.

2. As addon developer, i must say there is a common flow of deselecting-reselecting verts in edit mode for different tasks. Would be great if this flow should be able to keep active verts.

So it would be great to keep shadow history of last position of most recent active element in space (like vert.co in global space. not verts itself, since they may change during operations) and after mass-selection just restore active element closest to this point

Also, it is expected that "active element enforcement" should happen *after* operator is finished or update_from_bmesh called. not on every "v.select = True", i mean

So suggesting a common procedure of selecting active element after any "selection initialization":

1. Check global position of last known active element for current mode, and activate closest to it
2. In case there is no last known position - activate closest to 3D cursor

In T82359#1060426, @ronan ducluzeau (zeauro) wrote:

To me really "unselected but active" when nothing is selected is not such a big deal, what breaks me is unselected but active when you have other things selected

But that makes sense when using active element as pivot.
If you want to scale things selected and get them closer to active object that you don't want to transform ; that corresponds to a frequent case where selected means transformed and active means point of reference of transformation.

This just means that you're using some object as the 3D cursor. I'm wondering if it's worth the confusion of having active-but-not-selected as possible state. Why not just snap the cursor to whatever reference position you want to use?

In T82359#1060822, @Ilja Razinkov (IPv6) wrote:

Choice based on closest to mouse position would not be great decision though, imho... mouse position is generally random, this will feel mostly broken.

This depends on which selection method is used. With circle select, mouse position is far from random. With A the mouse could be anywhere, and indeed may not be the best choice. On the other hand, it does present something predictable, as artists generally know where their mouse is.

1. Make active element closest to 3D cursor (vert in EDIT, object in OBJECT, etc) among selected. 3D cursor generally always floating around of "Point of interest" during modelling sessions, so this will give reasonable choice in many cases.

You could use the same "point of interest" argument for the mouse cursor as well. The advantage of using the 3D cursor is that it's already in 3D, so there is less issues with depth. On the other hand, pretty much every artist uses a mouse or other pointer device, but not all workflows use the 3D cursor.

2. As addon developer, i must say there is a common flow of deselecting-reselecting verts in edit mode for different tasks. Would be great if this flow should be able to keep active verts.

So it would be great to keep shadow history of last position of most recent active element in space (like vert.co in global space. not verts itself, since they may change during operations) and after mass-selection just restore active element closest to this point

I don't know if this is a good idea. In any case an add-on developer can already do this.

Also, it is expected that "active element enforcement" should happen *after* operator is finished or update_from_bmesh called. not on every "v.select = True", i mean

I agree.

In T82359#1061962, @Sybren A. Stüvel (sybren) wrote:

In T82359#1060426, @ronan ducluzeau (zeauro) wrote:

But that makes sense when using active element as pivot.
If you want to scale things selected and get them closer to active object that you don't want to transform ; that corresponds to a frequent case where selected means transformed and active means point of reference of transformation.

This just means that you're using some object as the 3D cursor. I'm wondering if it's worth the confusion of having active-but-not-selected as possible state. Why not just snap the cursor to whatever reference position you want to use?

It's very far from "just", it's quite a few UI interactions. Right now, all one needs to do is set pivot to "Active Element" and (at worst) make two additional shift+clicks and at best none at all. Let's consider the hypothetical that "active" no longer exists as a pivot. Now, one would need to destroy their existing selection to pick a pivot object, snap the cursor to it, then re-build their selection. Or rely on the cursor transform tool with snapping options which may or may not be configured for that kind of snapping (if they're not, yet more UI interactions).

In T82359#1061962, @Sybren A. Stüvel (sybren) wrote:

On the other hand, it does present something predictable, as artists generally know where their mouse is.

Yes, user generaly knows where mouse is, but there is way too many cases when the mouse is 100% NOT at the "point of interest" regarding mesh/selection. When user clicks on operator button in the N panle - mouse will be in "random" position (regarding possible selection, created during operator execution). When user clicks on top menu item inside menu, to call some operator - mouse will be in "random" position, again. When user uses quick menu to make swipe gesture, use favorites or radial menu or pie menu, or right-click context menu, etc, etc - mouse will be definitely not around the place, where active item is expected to be.

The only case when mouse cursor can be placed on something meaningful - when user uses hotkeys. Pretty every other method to make something - will give "broken feel" (regarding active element defaults). Imho.

This just means that you're using some object as the 3D cursor. I'm wondering if it's worth the confusion of having active-but-not-selected as possible state. Why not just snap the cursor to whatever reference position you want to use?

You have to either change your selection or change your tool to snap the cursor. This is just too slow if you have to perform the action repeatedly. Moreover, the cursor doesn't necessarily have the same orientation (that you can use for rotations) as a face or edge when snapped.

wait so you are saying than having to click and activate one of the objects in a selection is done less often than using an unselected object as pivot?

please count:
Every time you select and want to perform an action on the selected objects you need o make one of them active.
Thats about 1000 times a day.

Using an unselected object as pivot of the selected ones is a corner case.

@Luciano Muñoz Sessarego (looch) any operation that forces you to lose your current selection is a destructive operation. Selection is work, and may not be trivial to create. In fact, it is only trivial in trivial cases. Losing selection means losing work.

In T82359#1079078, @Luciano Muñoz Sessarego (looch) wrote:

wait so you are saying than having to click and activate one of the objects in a selection is done less often than using an unselected object as pivot?

Obviously the frequency depends on what you're doing exactly. But more often than not you make a selection first and then decide where the pivot should be. So if you want to snap the cursor at that point, you have to destroy that selection, snap and recreate it - whereas setting the active element is just a shift-click.

If Blender let you freely pick your pivot point without affecting your selection, the whole thing about using the active element as the pivot would be a non-issue, but that is not currently the case. But that's a larger issue and rather out of scope here.

there are only 2 possible actions that you can be performing where the pivot is relevant, rotation and scale.
none of the countless other things you can do with a selection require a pivot where so I believe sacrificing "option" <<bug>> is a minor loss compared to the winning you'll get by not having to actively select the active object every time yo make a selection for something other than pivoting around an unselected object.

@Luciano Muñoz Sessarego (looch): there are more than two. Snapping - both transform snapping, and Snap To operators - also can use active as pivot or base point, either directly or indirectly. Align to Transform Orientation as well.

Also, you're framing it backwards. You don't "have to" actively select active object every time. You can do that when you need it. It's a useful option. If that option is removed altogether, there has to be an alternative that does not require you to do more work. Destroying your selection only to define a custom pivot is more work.

Agreed, if you select the object where you want to place the 3D cursor you can just then undo twice and get back to your selection and the 3D cursor will stay in that place.
And your selection isn't lost.

That just abuses the fact that cursor placement is not currently undoable. And using undo as part of a forward action is a much worse UI problem than the current Active/Selected situation.

Indeed, relying on undo to make progress is intolerable UX. Not to mention that in a scene with a few thousand objects, undoing a selection is even slower than making a selection :-\

Those are indeed true affirmations, Its just a workaround.
And i agree that the 3D cursor should A: be in the undo stack, or B: should have its own undo function (i'd preffer the later but that's for an other topic)

What I meant is it would be positive to conceive other ways to achieve that corner case without losing the selection.

Absolutely. Like I said, if a solution can be found to freely manipulate the pivot point without losing the selection, that would certainly solve this. Until then however, removing the current workflow would be a regrettable downgrade.

In T82359#1050426, @Brecht Van Lommel (brecht) wrote:

I think the long term solution here is to remove the concept of "active" for the most part, and have multi-object properties editing (T54862) everywhere instead.

I agree, "Active" needs to go as soon as possible. It is one of those primordial bad designs that unnecessarily complicates things, and has no place in a modern UI. It's like the right click select, or the compositor view as the editor background, or the 3D cursor that just sits there, or "Appending" a file, or calling Links, Libraries, or an "Outliner", that actually does not group, contain, or move things as it looks... Blender has so much cruft from the past.

From the user point of view, a Selection designates the Destination of a command or an edit they intent next. The Active selection introduces an unexpected Secondary selection, which most commands and edits do not need, and when they do, which is Source or the Destination is ambiguous. To the user, the word Active is what? Isn't selection active? Active most often means, a switch, like an active effect, an unmuted node, something turned On or Off, Activated, not a temporary selection followed by a command.

If Blender had multi object property editing earl on, this kind of hack design would have been unnecessary. If the compositor had a dedicated viewer area, nobody would think it is a good idea to put nodes and cables over the image you are working on.

So yes, bad designs might have temporarily solved problems when there were missing basic functions to support them early on, but they should be removed and cleaned as soon as possible to simplify future development and user experience.

Please stay on topic, for general suggestions go to devtalk.blender.org.

Some thoughts regarding removing "Active state" or making it "obvious".
In fact in many operations "active state" is not used in it "activity" meaning. It is frequently used in practical feeling "Select this first and that second". For example link data from one object to others, etc.
This is all what is really needed for many tasks with "active element".

So may be easier just to keep "selection sequence/order" somewhere with current selection? Active element then will be just "last" or "first" or not really needed at all, since all operations can be annotated with this new meaning - "Select target elements first and reference element last" or vice versa. The ability to get "selection index" for each selected element would open the whole new world possibilities for addon developers - since it will be possible to require specific order of selection for specific tasks, which is much faster than asking user to "Select this and press button 'remember source' than select that and press button 'remember target'", etc (just an example, many specific addons asking for such pre-memorization)

And it is looks like an easy feature to add. Just keep the "selection order" counter with current selection and increment on each "add" and remember in each added element current "selection order" (+api to get it back for element in selection). Like selection history in bmesh - but extended for any selection (objects, nodes, etc)

It may work not only for manual clicking, but for mass-selection too. For example in mesh edit mode user can click vertex (selection order = 1) then press "L" over mesh island (all vertex would be added to selection and they ALL should have selection order = 2) and than switch to face mode and click a quad (all 4 vertex will get selection order = 3). And we have selection with 3 "steps". In case last step is treated as "Active" - there will be 4 active elements (verts selected with quad) - and this is can be even useful, since ops can get center or choose specific vert among them or whatever.

This will give 100% strong definition of "active" and open many useful possibilities.

In T82359#1098595, @Brecht Van Lommel (brecht) wrote:

Please stay on topic, for general suggestions go to devtalk.blender.org.

Dear Brecht, my other criticisms are indeed relevant to this topic. If the clipboard was capable of vectors and groups of properties, the secondary "Active" selection for most data transfer operations would be unnecessary.

Sometimes, we must trace the reasons for a convoluted design, and find that it is the side effect of some other modern UI function missing, just like when you pointed out that properties should be multi editable.

My harsh criticism comes from the respect and love I have for Blender. 3D programs are often notorious for bad UI, because it is still a primordial and unsettled field in computer science. Overall, I still think Blender is the best in the industry.

To be directly on the subject, the proposition here is a good solution for the time being. In Python, an object must be made Active specifically from a selection operator, followed by an operator that needs Active, like Join:

l = bpy.context.selected_objects

for e in l:

  bpy.context.view_layer.objects.active = e

  bpy.ops.object.select_grouped(type='CHILDREN')
  if bpy.context.selected_objects:

    bpy.context.view_layer.objects.active = bpy.context.selected_objects[0] # << this can be automatic

    bpy.ops.object.join()

Note, how a programmer new to the API, has to learn about View Layers to complete the Join operation, highly unrelated to the task at hand.

The programmer will always have to worry about what object is being joined into what, because the operation will have completely different results depending on it. Using the active object for this seems completely logical and intuitive to me. As for the unwieldiness of setting the active object, that is addressed by operator context overriding elegantly and successfully.

As Brecht already mentioned, it's not possible or necessary to fully remove the concept of active/selected, just make it not be in the way when it's not needed. I think we should re-focus. Here are my takes on what have been said:

• Making multi-object properties editing default sounds great. I'd love to see the designs in T54862 implemented as an experimental feature, since it could potentially be a massive workflow break for literally all users if it is anything less than a pure improvement over what we have now. I think this would address Problem #1.
• Selecting hidden objects in the outliner in order to modify them in the Properties editor is something I do *constantly*. I could not live without it. Currently this is only possible because hidden objects are allowed to be active, which is great. Just wanted to point that out, as I think it's important to consider when tackling Problem #2.
• A very shy suggestion I'd have as to tackling problem #2 is a pretty wild one: What if we allowed hidden objects to be selected but this would reveal them in the 3D viewport to some capacity - perhaps only their outline, or with transparency, or both?

Not all methods or commands take a single argument. Some need a destination, and a source or even more. So for the internal API, operators should support this. However, when it comes to the UI, most operations are in the form of select destination, and give a command (left select, right command menu, or a key). If a special command needs more, it is the job of the UI provide this to the API, and probably better present a dropdown for further object selection.

What is not right, is that the UI should not show rare accommodations when they are not used most of the time, the active selection, the cursor, etc. This kind of bad design is now shaking the foundations of the API. Again, what does View Layers have to do with Joining a Mesh?

Imagine when painting, there always showed a clone source, even when you are not clone painting. That is what this active selection is like.

I agree with you there Mets (all of what you mentioned).

The only moment I think active shouldn't exist is when nothing is selected, but whenever something is selected there should be something active, that's my problem with the active/selected because I feel that the having an unselected object active is what makes this whole thing a problem. And also in rigs often you have an selected bone active and a deselected bone active at the same time.... bug ? maybe ? do i know how to reproduce it exactly? no. does it happen often? yes.

In the other hand what you said about
"What if we allowed hidden objects to be selected but this would reveal them in the 3D viewport to some capacity - perhaps only their outline, or with transparency, or both?"
I dont think its rare or even wild, I think the selection in the outliner and viewport should be consistent and objects should be able to be selected while non visible in the viewport anyways, heck they should be able to be active and selected even if in the viewport they arent visible, that would make selection even more "predictable" as right now when you turn off visibility of an object in the viewport you lose the selection of it.

And also in rigs often you have an selected bone active and a deselected bone active at the same time.... bug ? maybe ? do i know how to reproduce it exactly? no. does it happen often? yes.

That is relatively easy to reproduce if you understand how to make an object/element the active one.
And that is really easy to explain Active Object/ Active Element is the last one you clicked on.
That is not more complicated than that.

To obtain objects/elements selected and a deselected active one, You just have to shift double click on an element.
First shift click adds clicked element to selection and make it the active one. Second click deselects it.

So, active thing = last thing you clicked on.

That should not be perturbing.
What may be disorienting is if scripts or addons are changing active item without warning user.

@ronan ducluzeau (zeauro) It's not that simple in complex scenes, where you have objects close together, because there clicks just go through and you tend to cycle active object or deselect. It's very uncomfortable behavior, though I think this is more towards how selection is handled.

Absolutely. Like I said, if a solution can be found to freely manipulate the pivot point without losing the selection, that would certainly solve this. Until then however, removing the current workflow would be a regrettable downgrade.

I issued the feature request https://blender.community/c/rightclickselect/rmhbbc/ which I think solves the dilema without much problem.
It's about a snapping option to use origins' objects, and then using the 3d cursor like explained in there.

1. If there are Selected things, there is always one of those that is the Active thing.

The whole point of being active is being user specified.
There is no place for random, otherwise you will never know if your active object was actually specified by you.

There are Selected things, but none of them is Active: a sidebar/numerical/properties panel will not show information, and generally be empty without explanation why.

Because there is no user specified active one.

box-selecting multiple things at the same time.

Box selecting is non-picking type of a selection. You don't need active on a purpose when perform non-picking selection types.

2. If a thing is Active, it is also always Selected.

So as a result we can't deselect everything completely, or we will lose active object on every single deselect.

In T82359#1050426, @Brecht Van Lommel (brecht) wrote:

multi-object properties editing

This concept is useful for CAD systems, where all the properties of objects are equal, but it is not useful for objects with complex properties, like names, mesh data, materials or modifiers to display, link and propagate from Active to Selected.

In T82359#1047270, @Julien Kaspar (JulienKaspar) wrote:

I recall a similar discussion during the 2.80 alpha where the behavior was changed a couple times. Back then it was about hiding objects and if hidden objects should be allowed to be selected/active.

Yes, the ability to loose the Active object was applied to Exclude from View layer Restriction toggle option (EC RTO) - it turns to a selected object from the active one and is confusing in practice.

There is also a naming issue - when you make a selection you get "selected objects", since they are seleted so, basically we get
Selected objects = Active objects + Selected objects
which is quite recursive terminology, so during conversations with local developers who are not familiar with Blender we prefer to call "selected objects" as "passive objects" to clarify the context when setting scripting tasks.
(We have a lot of scripts that utilizes Active - Selected paradigm due to its flexibility)

We are familiar with such an issues, but their impact was so negligible, so they didn't cause any serious workflow problems.

For example, retrieving active 3d object can be done quickly with tab / tab / combination (enter editmode, enter isolation mode, exit edit mode, exit isolation mode) in 2.7x, turned to a bit less effective tab / tab A / combination in 2.8+.
We didn't even bother to solve this problem with one-line addons like bpy.context.scene.objects.active.select = True or bpy.context.view_layer.objects.active.select_set(True) because of a low priority.
For bones - you never have a practical need for editing a properties of an unselected bone, and so one.

So we never saw them as a huge problems to be solved, they was way more like tiny known issues.

Undoable 3D cursor don't have much sense, since you always need its the most recent location to perform operation, and the ability to restore complex selection via undo after setting 3D cursor.
It 3d cursor will be undoable it will be hard to define if its location is the most rescent, or if it was changed during some undo set.