Just been stung by this. I do not understand the basis for the "won't fix" status.

This is a very important issue and I can't believe Unity is burning their blender using user base in such a way. This really needs to be restored to the original functionality. And here's a couple reasons why:

1) No Ambiguity - Having the blend file directly in the Unity project removes any ambiguity that might exist if there was a FBX file created from a blend file. It might be hard or even impossible to tell which blend file the FBX was created from. Having the blend file in the project ensures that you have the exact file you are looking for.

2) Ability to make adjustments to file without having to reimport the entire file and updating any dependencies - For example, say I have a prefab that uses a humanoid model I created in blender but had to import as an fbx. When I imported the fbx, it takes me about 20 minutes to configure the settings for each animation (transform baking, events, etc). After importing and creating a prefab, I discover my model has duplicate geometry. Now, instead of just being able to directly open the blend file and making the fix, I must find the original blend file, make the changes, re-export as fbx, and then once again have to configure the entire fbx file import settings from the beginning. And that's assuming I have the original blend file. If not, I would have to create a new blend file, import the fbx, make the changes, then export as fbx and then reimport the fbx into Unity starting from scratch again. AND THEN I would have to find any dependencies that uses the original fbx which no longer exists because I've now just replaced it with an updated version, then then fix those dependencies (prefabs, animator controllers, etc etc etc)

3) Backup consolidation - Having the blend file directly in the project ensures that you have the most recent version of it.

These are 3 VERY IMPORTANT REASONS to restore the original functionality (which worked fine! I don't know why you changed it! Did autodesk put you up to this???) Please Please Please, on behalf of myself and all blender users, fix this issue.

If this is not going to be fixed it would be better to remove the ability to import animations from .blend files or add a warning message. I wasted hours because of this.

Echoing the other complaints on this issue - this is a clear regression that could be fixed by having the option to retain the old behaviour behind a checkbox.

How exactly are we supposed to import animations if we dont change that python file.

Because the only way I know/have been taught is to use the NLA strips, which this change disabled.

And as it's a matter of preference and the default behaviour is for most users to import separate actions, the default preference should match that expected behaviour.

This should be reverted/fixed; it breaks normal, expected behaviour.

The original issue mentioned in the resolution note is here: https://issuetracker.unity3d.com/issues/import-errors-when-converting-from-blend-to-fbx

This issue was resolved without any notes, and nobody outside of Unity has access to the FBX file that supposedly caused the issue. But I'm about 99% sure that issue 1117999 is an edge-case scenario. Using individual animations (in the form of actions) from Blender is the 80% use-case, therefore should be the default behavior. Adding the ability to choose how animations are imported is the correct solution. Making a backwards-incompatible change to a feature of Unity that's been around since the dark ages, and forcing everyone to change their workflow (or some auto-generated script), is NOT.

Agreed with others that this should be an interface option. It's a common workflow setup to have animations as actions, and requiring modification of internal Python files isn't a sound user experience.

I was having the same issue importing from blender 2.82a to Unity 2020.1.0b5. I modified the Python file as suggested and Bingo! I now have all the animations in Unity. Thank you for a really useful tip :)