For cygwin to use longer path names, the work is partially done.  Cygwin needs to use the unicode win api calls.  See here for a patched version does that:

  http://www.okisoft.co.jp/esc/utf8-cygwin/

Then, a couple of other things need to be changed.  Here is a quote from an email conversation with the author of the cygwin-utf8 patches:

(12/7/2006 7:11 PM)
 Wayne wrote:

    Thanks for your work on the UTF-8 patches.  I am using your cygwin1.dll for rsync backups.  I hoped it would bring the advantage of longer paths, but I am getting ENAMETOOLONG - "File name too long (91)" errors when using Rsync.  Using the wide (unicode) win32 api calls brings another advantage besides supporting special characters.  Many of the unicode (wide) functions support a 32000 character path length instead of 260 characters.

Note what the following page says:
  https://msdn.microsoft.com/en-gb/library/aa365247.aspx

<BEGIN QUOTE>

Maximum Path Length

In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. A path is structured in the following order: drive letter, colon, backslash, components separated by backslashes, and a null-terminating character, for example, the maximum path on the D drive is D:\<256 chars>NUL.

The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length. To specify that kind of path, use the "\\?\" prefix.

Note  The maximum path of 32,000 characters is approximate, because the "\\?\" prefix can be expanded to a longer string, and the expansion applies to the total length.

For example, "\\?\D:\<path>". To specify such a UNC path, use the "\\?\UNC\" prefix. For example, "\\?\UNC\<server>\<share>". These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory. Also, you cannot use the "\\?\" prefix with a relative path. Relative paths are limited to MAX_PATH characters.

When using the API to create a directory, the specified path cannot be so long that you cannot not append an 8.3 file name.

The shell and the file system may have different requirements. It is possible to create a path with the API that the shell UI cannot handle.

<END QUOTE>

It would be nice if you include in your patch the advantage of longer path names.  Items that would have to be considered:

    1) Where does cygwin use the windows MAX_PATH constant
    2) How is CYG_MAX_PATH used?  Can it be changed to something longer?
          (rsync uses #define MAXPATHLEN 1024)
    3) If there is the possibility of handling relative paths, these must be transformed to absolute.
    4) prepend "\\?\" to the path names before you call the wide api calls (such as before calling CreateFileW)

What do you think of this idea?

It is very interesting.

    I am sorry for my late response.  As for handling path
names in Cygwin, you should look into "class path_conv" in
winsup/cygwin/path.h first.  Its private member "char path[CYG_MAX_PATH]"
holds the path name to be processed.  It represents both a posix (Unix)
path name and a Windows path name, which is why it is difficult to
incorporate Unicode into the middle of cygwin1 and I have taken a wrapper
approach.

    Just redefining CYG_MAX_PATH and modifying the wrapper functions
may be sufficient to handle long path names.  But I do not have much time
to try it out for now.  I am hoping you will try it for yourself.  The
patch at http://www.oki-osk.jp/close/osk/index.html is open for everyone.
To compile it:

$ tar xf cygwin-1.5.22-1-src.tr.bz2
$ cd cygwin-1.5.22-1/winsup
$ bzcat ~/winsup-utf8-patch-08-09.diff.bz2 | patch -p0
$ cd ..
$ ./configure
$ make

You will get new-cygwin1.dll in i686-pc-cygwin/winsup/cygwin.  This is
explained in Japanese at
http://www.oki-osk.jp/close/osk/index.html
and I hope you read the command lines there.

Best Regards,

Wayne