You have already been given an answer - what do you find missing in the received answers???

If you have bit variables, you can locate them so that you can either operate on them as individual bits, or perform byte-sized operations on the overlapping container byte.

But you can not get a new byte container to span individual hardware-defined bits that resides in the SFR and controls the 8051 peripherials. If you copy such bits into a new container byte, you have a read-only representation of the physical bits at a specific point in time. If the processor changes the state of the original bits, then your new - manually combined - byte will not represent these changes. And if you change bit states in this byte, the changes will not be forwarded to the actual hw-controlling bits of the processor.

Next thing - you show sample code with union + C bit fields. But note that bit fields is a C construct to store multiple small state information fields more compactly into a larger integer. The C language do not have bit variables, and the bit field construct is intended to make the C source code look like it accesses normal struct member fields while the compiler performs logical and/or/not operations to set/clear bits within the containing byte.

The 8051 processor have true bit variables. And each group of 8 true bit variables are also accessible by a specific container byte. And depending on compiler used, there are normally some interesting language extensions how the user should declare bit variables.

The important thing is that this is that neither the original C bit fields or the hardware-specific bit variables in the 8051 allows any random mapping.

The C bit fields are always stored side-by-side (with optional high or low padding) in a container integer of an appropriate size. There are no addresses involved so you can't map the same bit field into two container integers.

Similar with the 8051. A specific bit variable is always hard-coded into a specific container byte. Some groups of bits controls specific hardware and happen to map into a SFR. Some groups of bits do not map to actual hardware and happen to map into a byte variable that an end-user application can make use of. But the mapping is always fixed. A specific container byte always accesses the exact same 8 bit variables.

I asked before, and I now ask again: Exactly why do you see a need for this? People tend to spend quite a lot of time complicating their lives because they refuse to tell others what problem they want to solve. So no one can suggest alternative solutions to the problem.

Note that the 8051 have specific instructions to set/clear/test individual bit variables.
The 8051 need more complex instructions to set/clear/test groups of bits in the byte container.
So it isn't always an advantage with view the container instead of the bits.

Anyway - make sure you have read up about the specific for bit variable declarations with your specific 8051 compiler, and how to declare the container variable that spans the 8-groups of bit variables.