Do not try to redefine a System` symbol. It is almost guaranteed to cause trouble sooner or later. Instead, here's how to deal with name collisions:

If your function is not part of a package, then make sure that you never used symbol names that start with a capital letter. This way you can avoid name collisions. The same applies to any non-public symbols used in packages.

If your function is part of a package: Let's look at a standard package structure first. Your package should look like this:

BeginPackage["My`"]

RemoveBackground

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

The definition RemoveBackground[...] := ... will fail in Mathematica 10, as RemoveBackground is a builtin now. What you need to do at this point is simply specify the full name, including the context, at the point where the symbol name is exported. This requires a single simple change. The package should look like this now:

BeginPackage["My`"]

My`RemoveBackground    (* <-- single change required *)

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

When you load the package, you will get a warning

RemoveBackground::shdw: Symbol RemoveBackground appears in multiple contexts {My,System}; definitions in context My` may shadow or be shadowed by other definitions. >>

but don't worry about it, it's just a warning. Notice the $ContextPath after loading this package:

$ContextPath
(* {"My`", "TemplatingLoader`", "PacletManager`", "System`", "Global`"} *)

Your package's context appears before System` in the context path. This means that whenever you type RemoveBackground, it will automatically refer to My`RemoveBackground and not to System`RemoveBackground. You do not need to and should not try to modify System`RemoveBackground. Just create My`RemoveBackground, as I described above, and you'll be able to refer to it as RemoveBackground, without explicitly needing to mention the context name:

In summary, the proper way to proceed: Do not modify the builtin RemoveBackground. Instead create an identically named symbol in a different context and let is shadow System`RemoveBackground.

Ideally, eventually you'll be able to rename your own function and all code that is using it. If that's not possible, (or as a temporary measure) use the solution from above. If you are the only user of your package, then I suggest you do rename your function eventually.

Do not try to redefine a System` symbol. It is almost guaranteed to cause trouble sooner or later. Instead, here's how to deal with name collisions:

If your function is not part of a package, then make sure that you never used symbol names that start with a capital letter. This way you can avoid name collisions. The same applies to any non-public symbols used in packages.

If your function is part of a package: Let's look at a standard package structure first. Your package should look like this:

BeginPackage["My`"]

RemoveBackground

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

The definition RemoveBackground[...] := ... will fail in Mathematica 10, as RemoveBackground is a builtin now. What you need to do at this point is simply specify the full name, including the context, at the point where the symbol name is exported. This requires a single simple change. The package should look like this now:

BeginPackage["My`"]

My`RemoveBackground    (* <-- single change required *)

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

When you load the package, you will get a warning

RemoveBackground::shdw: Symbol RemoveBackground appears in multiple contexts {My,System}; definitions in context My` may shadow or be shadowed by other definitions. >>

but don't worry about it, it's just a warning. Notice the $ContextPath after loading this package:

$ContextPath
(* {"My`", "TemplatingLoader`", "PacletManager`", "System`", "Global`"} *)

Your package's context appears before System` in the context path. This means that whenever you type RemoveBackground, it will automatically refer to My`RemoveBackground and not to System`RemoveBackground. You do not need to and should not try to modify System`RemoveBackground. Just create My`RemoveBackground, as I described above, and you'll be able to refer to it as RemoveBackground, without explicitly needing to mention the context name:

In summary, the proper way to proceed: Do not modify the builtin RemoveBackground. Instead create an identically named symbol in a different context and let it shadow System`RemoveBackground.

Ideally, eventually you'll be able to rename your own function and all code that is using it. If that's not possible, (or as a temporary measure) use the solution from above. If you are the only user of your package, then I suggest you do rename your function eventually.

Do not try to redefine a System` symbol. It is almost guaranteed to cause trouble sooner or later. Instead, here's how to deal with name collisions:

If your function is not part of a package, then make sure that you never used symbol names that start with a capital letter. This way you can avoid name collisions. The same applies to any non-public symbols used in packages.

If your function is part of a package: Let's look at a standard package structure first. Your package should look like this:

BeginPackage["My`"]

RemoveBackground

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

The definition RemoveBackground[...] := ... will fail in Mathematica 10, as RemoveBackground is a builtin now. What you need to do at this point is simply specify the full name, including the context, at the point where the symbol name is exported. This requires a single simple change. The package should look like this now:

BeginPackage["My`"]

My`RemoveBackground    (* <-- single change required *)

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

When you load the package, you will get a warning

RemoveBackground::shdw: Symbol RemoveBackground appears in multiple contexts {My,System}; definitions in context My` may shadow or be shadowed by other definitions. >>

but don't worry about it, it's just a warning. Notice the $ContextPath after loading this package:

$ContextPath
(* {"My`", "TemplatingLoader`", "PacletManager`", "System`", "Global`"} *)

Your package's context appears before System` in the context path. This means that whenever you type RemoveBackground, it will automatically refer to My`RemoveBackground and not to System`RemoveBackground. You do not need to and should not try to modify System`RemoveBackground. Just create My`RemoveBackground, as I described above, and you'll be able to refer to it as RemoveBackground, without explicitly needing to mention the context name.

In summary, the proper way to proceed: Do not modify the builtin RemoveBackground. Instead create an identically named symbol in a different context and let is shadow System`RemoveBackground.

Ideally, eventually you'll be able to rename your own function and all code that is using it. If that's not possible, (or as a temporary measure) use the solution from above. If you are the only user of your package, then I suggest you do rename your function eventually.

Do not try to redefine a System` symbol. It is almost guaranteed to cause trouble sooner or later. Instead, here's how to deal with name collisions:

If your function is not part of a package, then make sure that you never used symbol names that start with a capital letter. This way you can avoid name collisions. The same applies to any non-public symbols used in packages.

If your function is part of a package: Let's look at a standard package structure first. Your package should look like this:

BeginPackage["My`"]

RemoveBackground

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

The definition RemoveBackground[...] := ... will fail in Mathematica 10, as RemoveBackground is a builtin now. What you need to do at this point is simply specify the full name, including the context, at the point where the symbol name is exported. This requires a single simple change. The package should look like this now:

BeginPackage["My`"]

My`RemoveBackground    (* <-- single change required *)

Begin["`Private`"]

RemoveBackground[___] := "Package symbols"

End[]
EndPackage[]

When you load the package, you will get a warning

RemoveBackground::shdw: Symbol RemoveBackground appears in multiple contexts {My,System}; definitions in context My` may shadow or be shadowed by other definitions. >>

but don't worry about it, it's just a warning. Notice the $ContextPath after loading this package:

$ContextPath
(* {"My`", "TemplatingLoader`", "PacletManager`", "System`", "Global`"} *)

Your package's context appears before System` in the context path. This means that whenever you type RemoveBackground, it will automatically refer to My`RemoveBackground and not to System`RemoveBackground. You do not need to and should not try to modify System`RemoveBackground. Just create My`RemoveBackground, as I described above, and you'll be able to refer to it as RemoveBackground, without explicitly needing to mention the context name:

In summary, the proper way to proceed: Do not modify the builtin RemoveBackground. Instead create an identically named symbol in a different context and let is shadow System`RemoveBackground.

Ideally, eventually you'll be able to rename your own function and all code that is using it. If that's not possible, (or as a temporary measure) use the solution from above. If you are the only user of your package, then I suggest you do rename your function eventually.