The Unix tradition is that editors (e.g., "vi", "ed"), when given a non-existent filename, warn you that this is a new file, but then let you edit this new file, and when you next save, you save it with the name you gave in the command line.

Unfortunately, LibreOffice doesn't follow this tradition. If I run "libreoffice newfile.odt", or even "libreoffice --writer newfile.odt", All I get is an error message. A word processing window is *not* opened. Instead I need to use "libreoffice" or "libreoffice --writer" without a filename parameter, and then go and "save as" with the intended filename.

Why is the current situation bad? Because it makes a very common task very tedious for shell (command-line) users. A person (like me) who likes to work in a shell, I typically "cd" to some directory, and then decides to edit a file in it. But I can't "libreoffice newfile.odt", and if I do "libreoffice" without a file name, and then intend to immediate "Save As" the empty document, I discover that the default save directory *isn't* the directory I started in (possibly because a new libreoffice window often belongs to an existing process?), and it's tedious to use the menus to find this directory again.

So what I'd like is one of two solutions, with #1 prefered but #2 is probably easier to implement:

Option #1: "libreoffice --writer newfile.odt" should open an empty document (just like libreoffice --writer without the file name), but the next time I "Save", it should save it in newfile.odt in the proper directory (the current directory that the above command was run in).
If you think this breaks backward compatibility, I'd even settle for a new option, e.g., "libreoffice --writer -c newfile.odt" (-c for "create").

Option #2: "libreoffice --writer" should open a new window and remember the current directory, which will be used as the default directory to start in, for the next file operation (such as "Save As").