All rail types can be supported by trapdoors even when the trapdoor is open. This used to affect redstone repeaters, wire, and comparaters, but no longer does.
Steps to Reproduce:
Place a trap door down in the 'open=false' and 'half=top' blockstate
Place down one of the affected blocks in the "Notes" section on top of the trapdoor
Open the trapdoor with your hand, or redstone
Observed Results:
The block will not break, but instead float above the (mostly) empty supporting block.
Expected Results:
The block would break as there is no block beneath it to support it properly.
Screenshots/Videos:
[media]Notes:
Related to other supporting block issues:
MC-92758 MC-264563 MC-148202 MC-222212 MC-213638Standing signs and banners were added to this issue, but later removed, as they were not part of the original issue, and have unique placement behavior unrelated to rails (the last affected block).
Original Description:
(The original description of the issue when it was triaged, by @unknown)
When a trapdoor is in the flat form (Closed) it is possible to place rails on them. This would be fine except that you can then open the trapdoor and still have the rail on top of it. This is a fully functional rail, however when the block is updated by anything other than the rail, it pops off as it should directly after the trapdoor is opened. Attached is a video showing everything I have described.
This also applies to e.g. redstone dust and repeaters. Other blocks like torches do pop off though
Linked issues
is duplicated by
Attachments
Comments

Also applies to e.g. redstone dust and repeaters. Some blocks like torches do pop off though.
Can confirm in 20w51a. I've attached a screenshot.
Can confirm in 21w03a.
Can confirm in 21w06a.
Can confirm in 1.16.5 and 21w08b.
Can confirm in 21w15a.

Can confirm in 1.17.1 Release Candidate 1.

Also affects item frames and paintings, but that is probably intended.

Can confirm in 21w44a.
Can confirm in release 1.18. Would also like to make the following notes:
(Screenshots 16.16.37, 16.16.45): The redstone wire can be updated but only in certain ways. For example, this setup does not destroy the redstone, but removing the torch or repeater does. Note that placement order does matter; the redstone wire must be placed first. Subsequent ordering of the other two components is not important.
(Screenshot 16.21.38): This still applies with waterlogged trapdoors, and also applies to any kind of trapdoor.
(Screenshot 16.13.22): Updating the trapdoor does not remove the redstone wire even with power.
(Screenshots 16.14.32, 16.15.26): While in many cases removing the torch from the system (see note 1 above) will cause the redstone wire to break, this setup does not. See details below.
(Screenshot 16.29.50): The issue is independent of orientation, as long as [half=top].
(Screenshots 16.58.31, 16.58.36, 17.01.46): Using /setblock the trapdoors can be modified. What may be worthy of note is that some instances of /setblock will break the wire and some will not. Initially, let the right trapdoor be attributed [facing=south,half=top,open=false,powered=false,waterlogged=false]. When using /setblock to change the corresponding attributes to [facing=east,open=false] (first screenshot). This does not break the redstone wire. When attributing [facing=south,open=true] after the first command, it breaks both wires (second screenshot). When doing this independently of the first command, it breaks only the wire above the modified trapdoor (third screenshot).
(No screenshots): This is confirmed to work in singleplayer and multiplayer.
Can confirm in 1.18.1.
Can confirm in 1.18.2.
Can confirm in 1.19.

Can confirm in 23w04a

Can confirm in 23w05a

Can confirm in 23w06a

Can confirm in 1.19.4 and 23w16a
Can confirm in 1.20
Requesting ownership of this issue has it is outdated, and needs to be updated. I would also like to maintain it going forward.
Are signs really an issue here? They can be placed on top of bottom slabs too, heck wall signs can be placed on other wall signs with the same facing state. They never consider the block states of their supporting block.
Fair point. Noteworthy that banners also share the same behavior as standing signs (being placeable on top of other blocks which one would think doesn't support it).
Rails were the last affected block affected by this behavior in the original issue, so I can remove banners and standing signs if that's considered seperate behavior. I've added the original description to the issue for clarity.

Can confirm in 1.21
Opening a trapdoor should give a single block update in the direction of which the top face was facing