If you'd need any suggestions about the bone names, I'd "translate" their names if you could give a list about them (if that's not too much work). So you can implement them accordingly.
I mostly want this to be officially changed because it would make life so much easier for so many horse creators out there. Thank you!

For now, can you confirm that the metarig in my file gives you the desired results?

I just tested it, and yes, that looks way better. The functionality seems to be okay for me now. If I stumble upon anything troublesome alike, I might come back to this, though.
Just a suggestion, but changing the display preset of "foot_fk.L" and "foot_fk.R" to have the shin object "WGT-rig_shin_fk.L" / "WGT-rig_shin_fk.R" would make it easier to select. (If it just takes a click you might want to change, otherwise just keep it as a feature request).
Thank you for the instant reply back then. My apologies for not checking the file and giving feedback sooner.

@Demeter Dzadik (Mets) i believe would be better to add finger bones at the end of the limb rather than on top of the ik chain. the ik of rear limb would act strange if you do so.
Horses are unguligrades so the reported missing bone, if needed, has to be considered as a finger bone and should be appended after the existing chain.
This is the fix on your file.

In T78217#966013, @Ivan Cappiello (icappiello) wrote:

@Demeter Dzadik (Mets) i believe would be better to add finger bones at the end of the limb rather than on top of the ik chain. the ik of rear limb would act strange if you do so.
Horses are unguligrades so the reported missing bone, if needed, has to be considered as a finger bone and should be appended after the existing chain.
This is the fix on your file.

rigify_horse_test.blend2 MBDownload

That is a correct point of view, regarding that horses walk on their toes. However, the hoof has to be grounded. As far as I can see, the IK bone is not on the same height as the foreleg one which would result in weird control mechanisms. Artists also learn that usually all comparable leg joints roam around the same Z value (Blender-wise) for front and back. This could even be transferred in the upper joints not lining up exactly.
(I am not entirely a rigging expert neither is English my first language so I hope I understand you correctly, nevertheless.)
If you're going for the hoof as a finger bone, I am not sure, where you would make the horse move its leg accordingly (Also, front and back do not differ in this exact situation, so why is there a difference?). I'd also consider involving someone else who could say more about the motion itself. (Can ask externally if you'd like).

Edit: Here's an attachment about the hinds when I use the first one of the two test versions.

Whereas the second attachment shows about the same try to get the position as in the one above; resulting in wrong behavior.

Reference:

@J. O. (Papercut) i think you are just using the control in a bad way. That position is easily achieved by rotating the foot.ik in one direction and the heel in the opposite.
All paws in rigify act like that. This is not an issue, could have better automations, but the pose is easily achievable (we animated 3 awarded feature animation with horses, cats and birds using this setup).
I am attaching a screenshot and a posed file to illustrate that.

In T78217#966577, @Ivan Cappiello (icappiello) wrote:

@J. O. (Papercut) i think you are just using the control in a bad way. That position is easily achieved by rotating the foot.ik in one direction and the heel in the opposite.
All paws in rigify act like that. This is not an issue, could have better automations, but the pose is easily achievable (we animated 3 awarded feature animation with horses, cats and birds using this setup).
I am attaching a screenshot and a posed file to illustrate that.

rigify_horse_test_pose.blend2 MBDownload

Ah, alright, yes; now I understand how you mean it, sorry about that. I just got it working for my rig as well.
I still believe that the foot ik positioning is a bit off with this method, though. I imagine trying to put the hooves at an exact point on an uneven ground by using artificial animation, for example would result in quite a struggle since the IK controller is not at the same point where a horse's hoof is placed. Animations would need to be adjusted to a certain offset, which adds up workload for animators and coders who would use game engines to realize that concept. Imagine a human rig trying to place a foot exactly on the ground and having to find an offset position at first because the controller is off.
By duplicating the front leg setup and applying it to the hinds, we'd have a result of all four controllers sharing about the same Z-Location. This would make it easier for written code to detect a position and placing it correctly. It would block people that plan doing this in the later run, making it a harder issue to tackle than using the first setup version. For keyframe animation, people would go for the visible setup, but a machine cannot see this and has to be adjusted. Not very practicable in my pov.

Alright, please let me explain.
I see that you might have misunderstood the original reason I was asking for a fix, because there was a missing joint, in the first place.

I do understand how to fix the foot controller, and I appreciate your quick guide to doing so.

What I was aiming for to achieve by submitting this report is a rig that contains all vital joints in the hinds, just like the front leg does, so that there is correct control over its feet. You can't remove a joint at the human ankle and say it all works fine because you don't use human rigs often. The file from Demeter Dzadik (Mets) with just the copy of the front leg was okay, enough, fixed it. It was a simple idea, but that was just what was necessary. I was hoping this would get implemented because I know how horses walk like and how they work. The first one was the fix already and it leaves me completely saddened that this was not just seen as done, implemented, shared for everyone to use. It was a bug to fix, simple as that. I was further on trying to explain to you why the second try to approach this one is incorrect - because the front and hind leg work similar and thus should be rigged similar in that region.
Your approach about the walking mechanism of a horse in general is not incorrect about the theory of a horse walking on its fingernail - but a horse needs to stand with full weight on that toe on all times it's standing still. It cannot lift its hoof that easily. The approach you did was confusingly complicated and I wouldn't have seen this as a beneficial improvement at all.

Only the part where a human upper arm or upper leg is would be different for the horse.
I wouldn't have reported this as a bug if I wasn't having issues with animating a horse as realistically as I could with the current rigify input, if it was just an idea about further improving the rig I would have made a feature request. But this is something vital, in my point of view, as it limits the animation further down. We don't have horses like in "My little pony" where there is not such thing as a horse's pastern that is between hoof and fetlock. I know a lot of places where horses are not known as well as humans and being animated incorrectly, rigged incorrectly, modelled incorrectly. It is normal because we are no horses and there are less people knowing about horses than there are for humans.
I hope you understand me correctly, now.
Look at the original attachments and think about it. Why does the rigify horse have no fetlock joint if the real horse does have one and bends its leg at that position? I am not asking for a super fancy new creation. Copy/Pasting the front lower leg setup is enough to make it all work as it should. I know, the change looks minor in your point of view and is barely noticeable if you're not a horse enthusiast and know a huge lot about them, but it is missing indeed and it's limiting us horse people that are working with rigify.

I know nothing about horses, but you sound like you do, so in hopes that you've convinced Ivan, I've submitted the patch, but I'm not calling any shots here :p

Although I did take the liberty to rename the bones, see the patch for that and feel free to make suggestions there if I missed the mark.

as i stated this is not a bug. The metarig acts as designed.
We can debate rigify rear paw has a poor design and create limitations, but the reported issue is not considered a bug.
Moreover this limitation are not restricted to Horses (and other unguligrades) but extends to all quadrupeds setup.

let's try to make some light on why this is done like this:

• the setup is based on comparative horse-human anatomy, so the bone naming and placement reflects the corresponding human setup. This has been done like this to make easier for basic users understand how rigify works. That setup is a derivative of arm and leg.
• in a comparative anatomy setup, the patch by @Demeter Dzadik (Mets) moves the knee off its position making the whole ik ignore the upper part (equivalent to human thigh). This is not applicable to front leg since in the same comparative setup that part correlate to shoulder and arm and the ik should stop before shoulder.

• i don't think a bone is missing here. in my opinion this is a lack of automation at control level. In effect would be better to auto-counter-rotare the heel according to the foot. If we do so, the setup should work as expected. If still needed a super_copy (hoof) bone can be appended after the chain as described in my first proposal.

I am attaching a video of the resulting setup and the rig, including the source mesh upon which the metarig was designed. I just added manually the automation. If it works we can decide how to handle this in code.

After further analysis on the test rig i believe there is an issue that persists in this setup. There is one movement that cannot be achieved with the current (and modified) setup that is possible with @Demeter Dzadik (Mets) first one: the rolling back and is the last pose before stance. The heel rotation cannot be compensated by the foot_ik since it should stay in place on the floor.

F8655310
the green arrow shows the impossible movement.

i will test further improvements to the unguligrades limb.

This discussion should continue in a correct design thread though since this is a design issue.
Will create a design task and link this page.

In T78217#966577, @Ivan Cappiello (icappiello) wrote:

@J. O. (Papercut) i think you are just using the control in a bad way. That position is easily achieved by rotating the foot.ik in one direction and the heel in the opposite.
All paws in rigify act like that. This is not an issue, could have better automations, but the pose is easily achievable (we animated 3 awarded feature animation with horses, cats and birds using this setup).
I am attaching a screenshot and a posed file to illustrate that.

rigify_horse_test_pose.blend2 MBDownload

Hello, Ivan. I downloaded the file, but when I try to open it in Blender 2.79, I got an error message "File written in new binary..." Is there a сhance to open it in my old Blender?

In T78217#1036359, @Olesya (Olesya) wrote:

Hello, Ivan. I downloaded the file, but when I try to open it in Blender 2.79, I got an error message "File written in new binary..." Is there a сhance to open it in my old Blender?

sorry, this will only work in 2.8+

Also I found that it is better to have 3 neck controllers instead of one to make left - right turn more smooth, but I do not know how to make it. I mention that you added more controllers to horse body. I hope, you can help me. Thank you!

there is a center control to bend the neck. Ik on neck is also supported and can auto-extend the neck if you move te head control. Unfortunately you can't effectively mix the ik and fk setup.