Main Part of the Feature:
New predicates:
match_block but for front: "match_block_in_front"
match_state but for front: "match_state_in_front"
is_same_block but for front: "is_block_in_front" - optional (I think)
is_same_state but for front: "is_state_in_front" - optional (I think)

implied from: https://discord.com/channels/778999838392975372/779005460321009665/1177355352191291598
What it would do: see: https://discord.com/channels/778999838392975372/779005460321009665/1212136507427520612
Used in model file for pink side which the texture is to be rendered
A new layout would likely have to be made because you can have the case where the red squares have grass but the blue square doesn't so 6 different textures are needed where:
1 - Default (no grass in blue or reds)
2 - Texture where the red squares have grass when the blue one doesn't
3 - only the Left red square has grass
4 - only the right red square has grass
5 - only the blue square has grass
6 - All blue and red squares has grass
Alternative way where it just detects/finds the matching block in front then outputs a set format which you can specify and pair this with some sort of "advanced" texture format

A quick Illustration for people to see

left images - a low quality of the grass block
right images - state of blocks around
red - do not match
orange - either of the pair of oranges match
green - just this block needs to match
blue - irrelevant
pink - where the texture is rendered itself

edit: a better illistration

renamed title because connection detection offset would not just do better grass, it could also do:

• 3D Connected Textures
• Better Grass
• Better Snow (works simularly to how 3D connected textures would work
• Fixing this image

I have had thoughts and realized what I want in #52 could be done in a different, potentially better way. So basically contined in a different potential way as #63