Memttm

Having them as separate, labeled values for different solid/non-solid related properties, labeled accordingly, would probably be best, as there are also other properties controlled by solidity, like mob suffocation and whether minecarts bounce off of them, that could be separated into separate modifiable properties, maybe under a “solidity” grouping, as the multiple separate values for solidity in different areas seem to also cause issues for the Mojang devs, as the new shelf block has the same issue mentioned in your bug report, namely cutting redstone while not conducting signals or visually cutting it.

Also the issue where redstone can be visually cut/not cut while behaving differently needs to be fixed.

“This behaviour should be impossible and is not seen in any vanilla redstone components.”

Well… This exact issue is seen in about 20 - 30 ish vanilla blocks, which either visually cut redstone while not conducing it, or visually not cutting redstone lines while conducting power and actually cutting the visually uncut line. Also, comparator readings through conductive blocks are based on the redstone_conductor property, so they can also diverge from the actual conductivity of the block.

An incomplete list, based on memory:

Conducts, doesn’t cut visually, blocks comparator readings:

Target block, Bell, dripleaf.

Doesn’t conduct, cuts visually, allows comparator readings:

Piston, Sticky Piston, chain (both copper and iron), sniffer egg, path block, farmland, chorus plant, chorus flower, copper grate, also the shelf I think.

Special: Doesn’t conduct, cuts actually not visually, denies compartor readings:

Mob heads

Skulk shrieker

Copper bulb (also cuts visually as well as properly)

While this is strange, several mechanics here are used in actual vanilla redstone builds, and fixing this bug would annoy/anger many in the Bedrock Redstone community (that includes me, as I have used the piston/sticky piston and copper bulb properties in some of my redstone builds.)

Notably there is an earlier bug report related to this about comparators reading through chains (MCPE-138549), where many comments noted it uses in shuklerbox loaders (not sure how it is used though, I haven't tried to build one)

As a result, I don't really want nor expect Mojang to change this, and if so I would prefer them to make it either have some kind of consistency or some visual indication in game.

However, 4 blocks which used to have strange properties were fixed relatively recently, namely tnt, sea lantern, mangrove roots, and beacons, so some of the more obscure strange blocks may be fixed in the future.

Playing on an iPad 8, the issue is far worse than in the videos above, freezing for 5 to 30 seconds or more, but rarely (both on realm and not on realm) However, this may be affected by my render distance being set to 15 chunks (5 more than normal max) (done by editing the options file). However, I would expect that lag from higher render distances would be consistent, instead of occurring briefly in massive freezes. (This may be related to chunk saving/loading, as I remember spotting a similar ish older bug report about lag spikes when auto saving on Xbox.)

This setup can actually detect if you are just standing near any redstone inputs anywhere in the world. Very strange.

Based on my own testing of the issue, it seems that the moving block is controlled by the piston that moved it. (Discovered by cloning the moving block somewhere else while being moved. It doesn't revert to a regular block when movement finishes, and extending/retracting the piston that created it causes it to move, no matter how far away it is. Destroying the piston causes it to revert to a regular block where it should have reverted to earlier.)

Based on that, I think that what is actually occurring here is that the reverting of the moving block is done during the step of updating the piston that moved it, so the issue is the same as MCPE-16371. The solution here is to have pistons finishing movement always updated before pistons starting movement. There is already a feedback suggestion on that fix.

Interestingly, I have actually managed to implement this fix using commands, by destroying and then replacing the piston midway through movement, which makes the moving blocks revert faster than they are supposed to. This also provides more evidence that the moving blocks are controlled by the piston that created them.

         I noticed some similar posts about blocks having strange mixed solid/non-solid properties, so I decided to test some of the solid/non-solid properties of most blocks in the game, and I found many more that have strange solid/non-solid properties, a total of 25, but there may be some I missed. Some of these properties are useful, namely the cutting of redstone lines by copper bulbs and comparators reading signals through pistons, and I think those should be kept. I think the posts should be set up to be one post per strange solid/non-solid behavior, ie "visuals of redstone line being cut/not cut don't match behavior" should be one post, "comparators reading/not reading signals through blocks they shouldn't/should" should be another post, and "minecarts not bouncing off of blocks they should" should be another post. Each post would list the bocks affected.