Eggfur

I believe what is happening is that they glitch out the side of the chute - only appearing to spawn in mid air. Adding an extra layer of solid blocks around the chute fixes it. 

My view: not a bug (or at least not the bug you've described)

Bonemeal based mechanics have always been different between bedrock and Java, e.g 1 tall flowers can't be bonemealed in Java whereas they can produce a bonemeal profit in bedrock.  Rates for nether plants on crimson nylium were nerfed in Java, whilst in bedrock they produce enough for a much faster bonemeal farm than moss can produce.  So moss farms in Java are kind of a feature parity with bedrock,  just not as good as what we already have. 

It's either a bug that it visually redirects redstone, or it's a bug that the redirected redstone doesn't affect the bell. It would be most useful if the bell (a solid block) would be both powered and activated from the redirected redstone line (as it is with a straight line). This would enable a target block equivalent, without the producer/consumer issue that is believed to be the problem with target blocks themselves doing this on bedrock. Albeit a noisy, villager scaring equivalent...

This is related but may be a different issue. I'm adding here for now. It's about villagers who are able to link to out of range workstations that are made within range by a different villager. My comment is localised to within a single village though.

We normally expect villagers to claim beds and workstations in a range of 16 blocks horizontally and 4 blocks vertically. However, the next villager in the queue for a workstation is able to connect to a workstation within16 blocks horizontal and 4 blocks vertical of any villager in that village. There is an exception related to path-finding described below

Steps to reproduce:

1) Spawn a villager (A) in a 1x1 space. Place a bed and a workstation within 16 blocks horizontally and 4 blocks vertically. A links to the bed and workstation, and this creates a village.

2) Spawn a second villager (B) in the same 1x1 as A. B has no bed or workstation, but becomes a village dweller.

3) Place a workstation 20 blocks horizontally from B. B is unable to link to the workstation as it is out of range.

4) Spawn a villager (C) within 16 blocks vertically and 4 blocks horizontally of the workstation (including right next to it), in a 1x1 space. B connects to the workstation

==> I interpreted this as B being next in the queue for a workstation, which was made available for connecting by C. Indeed if you were to add B1, B2, B3 before C, they all claim workstations in the order of spawning. However....

Repeat the above, but this time spawn C in the open so he is able to path-find, but still within range of the workstation. C walks towards the workstation and connects to it. B is left with no workstation.

The act of path-finding towards the workstation by C appears to allow C to claim that workstation He won't/can't claim it if he can't path-find, even if the workstation is right in front of him - until B gets his own workstation or is killed leaves the village.

This issue still exists in 1.16.201, although at this stage I'm not really expecting it will be fixed!

The description, images and videos above are still correct for describing 1.14 and current 1.16.201 behaviours

Affects 1.16.210.53

This breaks multi-floor water elevator designs as well.

Confirmed in 1.16.100.54 as well.

That means it's not as a result of the change to harvesting efficiency in 1.16.100.57.

It's not location specific, as I built it in multiple locations and it always works in 1.16.40 and always breaks in 1.16.100.x. It's also not dependent on spawn order of the entities. So there has been an unadvertised change that breaks at least one type of villager crop farm. That feels like a bug to me, and pretty inconvenient that farmers are unable to replenish enough resources to replant. If it was a necessary change to fix something else, then fine, but if there was no reason to break it then I say it walks like a bug and, er, quacks like a bug.

Confirmed on 1.16.100.58

The issue for me is around impact, as there were already parity differences between editions in terms of the number of plants produced when bone mealing. The impact of the change is negligible on Java but significant on bedrock which wasn't accounted for when making the decision to introduce a change to the feature on Java (I don't accept it was a bug, and there are other cases where Java feature requests are raised as bugs and new features added on the back of that). So as a feature request: can this be resolved as I've suggested above and Java brought back into parity. That solves the problem some people had with picking up "useless" roots, but still enables automation on bedrock where roots are useful. 

I feel really uncomfortable with the principle that the Java Devs make feature changes which break parity and bedrock is then led by the nose down those same changes.

This has been closed now as WAI. it's not a duplicate though. MC-170900 should never have been a bug, it was a feature request and by "fixing" it this has introduced a parity issue. Anyway it appears that the parity issue is intentional

I don't understand the relevance of that statement. It was intended functionality that these could be collected without shears. That functionality was released into both versions. Hence MC-170900 was never a bug. So by changing the functionality this is Java edition introducing a parity issue, not bedrock. The original MC-170900 was never a bug, this isn't a bug; the only actual bug is MC-196492 which has been closed as WAI. i vote this is closed as WAI and we accept the difference.

But if it's ok to raise feature requests as bugs, like on Java, I'd suggest this is changed to drop nothing if mined, but to drop  items if destroyed by water flow or pistons

In fact this bug is all back to front. The whole point of parity issue bugs was to reduce the number of parity issues being created, preferably before release. So the problem is the change to Java Edition, not the existing functionality of both Java and Bedrock released versions. As such, I've raised bug MC-196492 on the Java Jira as a parity bug against 1.16.2 pre-release 1.

Can anyone point me to the documented feature against which the Java bug (MC-170900)r was raised? It strikes me that this was a feature request dressed up as a bug and is now being proposed as a parity update.

This change if implemented in bedrock will completely nerf the use of nether plants to generate a bone meal farm. I'm strongly opposed!

How can this ever have been a bug? Has it ever been a documented feature that you need shears to collect nether plants? How come feature requests get raised as bugs and then changed. This is specifically an issue as it's now been raised as a parity issue for bedrock, where nether plants are extremely useful for bone meal farming

Parity issues can be raised as bugs.

Interestingly, the ability of the target block to conduct redstone power was introduced to Java on the back of a bug report, even though there was no indication that the developers intended this. The "bug" was voted for 6 times and introduced as a new feature 2  months later: MC-173198. This bug currently has 66 votes...