Useful information to include:

• Explanation of how the feature/change should work:
  copy pasting strings containing line breaks should leave them unchanged instead of deleting everything after the line break
• Some rationale/use case for a feature. My general approach to designing new features is to ask yourself "what issue are we trying to solve" and then "is this the best way to solve this issue?":
  being unable to copy paste string with line breaks is bad if you are trying to do anything using the edit program

That could work, or it could have a return value for each line

Or something that preserves current system and don't add extra complexity like "paste", "current_first_line", "full_paste" just adding one extra return value to paste event? Old programs would use first one without having issues and new programs that can and are aware of it would use second? It would be highly unlikely it would break anything.

A bit of side-topic if we are talking about changes to paste, would it be possible to make someone pasting in a file trigger "file_transfer" event?

I ran into this while trying to put together a simple script that would let you paste your clipboard into a named file, for the purposes of using an IDE to write CC scripts and then adding them to a computer on a multiplayer server, without needing to upload them to pastebin as an intermediate step. It would have been nicer for rapid development and testing, being able to just control-A-C, alt-tab, up arrow, control-V, and the whole thing is updated and ready to test.

Similar to the backwards-compatible idea of adding another return value, what about a new event with third value as a boolean indicating whether there are further lines that were pasted in the same operation? In that way, you could do something like:

local lines = {}
repeat
	local _, line, moreLinesWaiting = os.pullEvent("multipaste") -- or longpaste, or fullpaste, or whatever
	table.insert(lines, line)
until not moreLinesWaiting
local content = table.concat(lines, "\n")

Or even, if we're adding a new event already anyway, it could just provide the full text of the entire paste directly.

[EDIT] Realised belatedly that I posted this idea only half-backed, so I fixed it.

It's probably a sensible idea, but I have no clue how to do it without causing problems for existing programs.

Idea I just had: split multi-line pastes into the first line and the proceeding lines, queue a "paste", "first_line_here" event for the first line, then another event for the remaining lines somewhat like: "paste_extra", "line_2\nline_3\nline_4".

Unless there's some case I haven't thought of, this mostly preserves compatibility since paste's behavior is still the same.

Drop-box style local folder syncing? This would require file transfers via the minecraft network code, so don't know how feasible that would be(or who would be willing to work on it), but would likely solve the problem in transferring source if pastebin/http is off or the server is local.

Multi-user security could be handled by requiring access to the computer/turtle console to enable.

But this is probably just a pipe-dream.

It's probably a sensible idea, but I have no clue how to do it without causing problems for existing programs.

That said, would contend that pasting large blocks of code into edit is never going to work - there's also a length limit on how much you can paste, and while we could lift it a bit, it's still going to be constraining.

Most often when people want to paste multiple lines they are wanting to copy their code onto a server that has HTTP or pastebin broken or disabled. If it's disabled then appeal to your server admin that CC is very secure with it's HTTP and that the can whitelist stuff like pastebin and github with no issue. If it's broken then there is the wget program and the server admin can also install a patch for the pastebin program. If your server admin doesn't want to do any of these then tell them to uninstall the mods that they don't want to support properly and find yourself a new server,

I might be a bit overly harsh about this.