The IK solvers and rotation limits of FinalIK were built from the ground up with extendability in mind.
Some of the components of FinalIK, such as BipedIK, are essentially little more than just collections of IK solvers.
Before you can exploit the full power of FinalIK, it is important to know a few things about it's architecture.
The difference between IK components and IK solvers:
By architecture, IK solver is a class that actually contains the inverse kinematics functionality, while the function of an IK component is only to harbor, initiate and update it's solver and provide helpful scene view handles as well as custom inspectors.
Therefore, IK solvers are fully independent of their components and can even be used without them through direct reference:
You now have essentially a custom IK component.
This can be helpful if you needed to keep all the functionality of your IK system in a single component, like BipedIK, so you would not have to manage many different IK components in your scene.
All rotation limits in Final IK extend from the abstract RotationLimit class. To compose your own, you would as well need to extend from this base class and override the abstract method
In this method you will have to apply the constraint to and return the input Quaternion.
It is important to note that the input Quaternion is already converted to the default local rotation space of the gameobject, meaning if you return Quaternion.identity, the gameobject will always remain fixed to it's initial local rotation.
The following code could be a template for a custom rotation limit:
The new rotation limit gets recognized and applied automatically by all constrainable IK solvers.
When creating more complex IK systems, you will probably need full control over the updating order of your solvers. To do that, you can just disable their components and manage their solvers from an external script.
All IK components extend from the abstract IK class and all IK solvers extend from the abstract IKSolver class. This enables you to easily handle or replace the solvers even without needing to know the specific type of the solver.
Controlling the updating order of multiple IK components:
When your character has Animate Physics checked (UpdateMode.AnimatePhysics since Unity 4.5), you will need to check if a FixedUpdate has been called before updating the IK solvers in LateUpdate. Otherwise the IK solvers will be updated multiple times before the Animator/Animation overwrites the pose and accumulate resulting in a high frequency flicker. So the way to update the solvers with Animate Physics would be like this;