I'm a fan of the second you proposed.  The number 90 came out because you have to stay under 260 with total path length, and after c:\msysgit\git\t\trash directory.t7410-submodule-long-path\ -- you've already got a lot of length used.  90 (just from testing) happened to be a pretty good number to compensate for this.  I suppose this test could be marked for msysgit only (and then the length of ```pwd -W``` could be subtracted to find available length), but there's also some value on other platforms to the test (just maybe not as much in its current form).

I'm seeing more layers to this problem as I look beyond the mingw porting layer, since large portions of Git use PATH_MAX as the size of a stack variable to store paths (and sometimes, there's additional space reserved for other characters -- in path.c, there's even an extra 100 character padding reserved with submodules, which could easily explain why this so quickly hits the path limit -- you get bad_path arbitrarily early).  Other places use strbufs to hold the path, and just assign PATH_MAX for a default size.  Ultimately, I think the "correct" fix is to use strbuf more liberally, as this could increase the path length limit arbitrarily, even on other platforms (such as GNU/Hurd, which doesn't have a maximum path length) -- basically, http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html seems to be rather relevant in this scenario.  Also, I think this may be more palatable to the upstream maintainers, since it's not just a one-off Windows fix, but an enhancement for all platforms.  I know you and the other commenters are also actively involved in upstream development, so certainly, your opinions on this matter are welcome.  But, in terms of working towards the ultimate goal of how to achieve long file support in Windows, this seems like the best step forward.