Sorry for the slow reply.

I tried something similar to your second proposal (mimicking
`org-attach-dired-to-subtree'), but more convenient in my opinion and
not losing the method choice. It mimicks the mechanism to store links:
there is a new command `org-store-attachment' (to which one could give
a global keybinding such as `C-c a`) that stores an attachment to the
current buffer in a new variable `org-stored-attachments', and
`org-attach-attach', when called interactively, prompts to select an
attachment from this variable if it is non nil (the attachment is then
removed from the variable). See attached patch (yes I've signed the
FSF papers).

"Storing an attachment" simply means storing the buffer file name or,
if there is none, the buffer name, to the variable (there may be a
better terminology for that). Then `org-attach-attach' detects if the
"file" is actually the name of a non-file-visiting buffer and uses
`write-file' rather than the specified or default method in that case.
So we keep the method choice and don't need to add a specific command
for buffers to the dispatcher. If you think it's not worth introducing
complications for allowing to attach non-file-visiting buffers, we
could simply prevent this in `org-store-attachment'. I also made it so
that if `org-store-attachment' is called from a dired buffer, then the
file at point is stored rather than the dired buffer itself.

This can certainly be improved, but I hope it is sufficient for you to
judge whether you think it is a good idea or not. Possible
improvements I thought about:
- When `org-store-attachment' is called from a dired buffer and there
are marked files, we could store these rather than the file at point
(similar to `org-attach-dired-to-subtree').
- We could add a mechanism for making `org-attach-attach'
unconditionally read a file name, ignoring `org-stored-attachments'
(i.e. a prefix argument, distinct from the one to visit the attachment
directory). We could also add a command to clear
`org-stored-attachments' from the dispatcher.
- We could check whether the file to attach is modified and prompt the
user to save it in that case (this is actually independent from the
present discussion).

I understand that other users may not like this mechanism and prefer
different solutions (or leaving things as they are). There was a
recent suggestion to make the list of commands in the attachment
dispatcher customizable:

http://lists.gnu.org/archive/html/emacs-orgmode/2018-06/msg00139.html

Do you think it would make sense to do so?

Thank you for your attention.
On Thu, Jun 21, 2018 at 5:47 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> Eric Danan <eric.danan@u-cergy.fr> writes:
>
> > When the file to attach is already open in emacs, it is generally
> > faster to select it from the buffer list than navigating to it through
> > the file system. This patch adds a `b' command to the attach
> > dispatcher that reads a buffer and writes it in the attachment
> > directory.
>
> Thank you.
>
> One issue is that we're losing the method choice (symlink, copy,
> hardlink).
>
> However, `org-attach-attach' already offers to start file system
> navigation from a Dired side buffer, if any. We may extend this idea: if
> there is a buffer currently displayed in another window, but no Dired
> buffer, offer its default directory as a start for completion.
>
> Another idea is to create a new function that will attach the current
> file to the subtree in another window. See
> `org-attach-dired-to-subtree', for example.
>
> If you haven't signed FSF papers, you need to add TINYCHANGE at the end
> of the commit message.
>
> Regards,
>
> --
> Nicolas Goaziou