OK -- so you are using a Palette to run these, which is Important Information. It means you need a macro for each entry (unless you drastically change your workflow -- bleurgh!) and can't use a single macro and trigger detection*.
There are still many ways to break this up, and one way would be to have
- Your "calling" macros
- A macro to extract Mail URLs, returning a list
- A macro to extract Safari URLs, returning a list
- A macro for each of your output options
So sub macros or subroutines? In brief:
- A sub macro can accept zero or one parameter (though that can be structured data containing many values) and cannot return data unless you use a shared (Instance or Global) variable. It can be run synchronously or asynchronously (and then won't have access to Instance variables)
- A subroutine can have zero, one or many named parameters (named means they are easier for you to use) and can return one value (though that can, again, be structured data). It can also access Instance and Global variables, and can only be executed synchronously
(There's more about variables and especially their scope on this Wiki page.)
You can use either here -- since we're demoing, let's use both 
We'll use sub macros for getting the URL list, passing the result back via an Instance variable. So, for Mail:
...and for Safari:
And we can easily test those -- Safari test shown below. Note that you must use the same variable name as in your subs, and we're doing to display the variable's value twice to prove that is first empty and then has values.
For the "output" macros we'll use subroutines. That's because we're going to get cute and pass in multiple options for some, and that's easier using the subroutines' labelled parameters.
Display is easy:
Note that the subroutine doesn't care what's data is passed to it, it'll just display it regardless.
And we can quickly test that:
Notice how we have to use the correctly-named Instance variable, as set in the sub macro, to pass the data to the subroutine. But the subroutine routine doesn't care "internally" -- the data passed to it is stored in Local_theURLs and that's the variable it uses.
For file appending we'll pass in both the URL list and the path to the file we want to append to:
...and this time our test macro will need to pass two arguments:
Which just leaves subroutines that return data. Nothing obvious leaps out from your list, so how about one that formats the URLs as an unordered list of links in Markdown, ready for you to add link text manually, passing it back so you can append it to the text file:
(Note the ticked "Returning a value" option and the "Return" Action at the end.)
Which we can use like so:
Hopefully that'll give you some ideas about how you can use sub macros and subroutines across your other macros. I've probably not explained some concepts particularly well, so if you've any questions just ask!
All the macros from above:
Subs Demo Macros.kmmacros (21.1 KB)
* Not actually true. You could put your getters and all your different output options into a single macro as before, then build your palette with aliases to that macro which passed the appropriate option choices by parameter. But that's possibly even more confusing, and not so generally useful.
