You're misstating situation. On Windows there isn't a single character that represents EOL. 0d by itself isn't an 'EOL character' and 0a isn't either. EOLs are specified by a sequence of two characters, 0d0a. Our code looks for those two characters and when it encounters them it substitutes the FTP EOL sequence, which happens to be the same (on Windows), i.e. 0d0a. When edtFTPj/PRO encounters 0d without a subsequent 0a character then it just treats it the same as any other character and sends it straight through the data channel.
Yes, we could have done either of two things instead, (1) ignore the single 0d, or (2) pretended that the single 0d was actually a 0d0a and treat it as an EOL. But what we decided to do was to just send it through the data channel by itself.
That is the decision that was made somewhere between 1999 when edtFTPj was first released and now. It's not wrong, because this situation is not covered by the spec. It's simply the decision that we made. If we were to change it to suit you then someone else would complain that the single 0d had been changed.
Having said that, you can purchase the source-code and change it to behave the way you want it. Or, depending on how your code is written, you can probably also preprocess the file or stream before you pass it to edtFTPj/PRO.